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ABSTRACT 
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I. INTRODUCTION 


A. PURPOSE. 

TWs thesis defines the satellite disdpline and protocols for the second generation of 
the Officer in Tactical Command Information Exchange Subsystem (OTCIXSII). This 
document provides the detailed information necessary for the implementation of the 
OTCIXS n communications protocol. It could be used to define and develop the 
OTCIXS n satellite link software. 

The OTCIXS n network protocol shall consist of distinct protocol layers: Physical, 
Data Link, and Network layers. The fimction supported by each of these layers are: 

1. Physical layer - The Physical layer controls interaction of OTCIXS n equipment 
suites at the hardware level. 

2. Data Link layer - The Data Link layer ensures an error-free transfer of information 
between OTCIXS n subscribers. 

3. Network layer - The Network layer controls the allocation of the network 
resources among the OTCIXS n subscribers and provides the vehicle for transporting 
OTCIXS n subscriber to subscriber transactions. 

A fourth layer, the Transport layer, prowdes the actual subscriber to subscriber transaction 
service; that is, the transfer of formatted computer-to-computer data and teletype 
messages. This layer is beyond the scope of this thesis. A description of this transfer layer 
protocol is defined in the Tactical Data Information Exchange Subsystem (TADIXS) 
Interftice Design Spedfication, Volume I. 

B. FUNCTIONAL SUMMARY OF THE OTCIXS n. 

OTCIXS n will support inter and intra battle group Tactical communications. 
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including delivery of Over-the-Hoiizon Targeting (OTH-T) information. OTCDCS n will 
support ship-ship, shore-ship, and ship-shore tactical data exchange between user systems 
as described in the following subparagraphs. 

1. Communications Link. 

OTCEXS n operations are transparent to the use of either Fleet Satellite 
(FLTSAT) or Leased Satellite (LEASAT) satellites. When hmctioning in Demand 
Assigned Multiple Access (DAMA) mode, OTCIXS n operates in a half-duplex manner at 
a data rate of 1200 or 2400 bits pCT second (bps) in a permanently assigned timedot of an 
uhrahigh fi’equen(^ (UHF) DAMA chaimel to support subscriber communications. When 
functioning in Non-DAMA mode, OTCKS n operates in a half-duplex maimer at a data 
rate of2400 or 4800 bps using a dedicated UHF chaimel. In either mode, the 
communications link implemented by OTCIXS n is referred to as an OTCIXS n radio 
frequency (rf) network. In the coverage area of an individual satellite multiple OTCIXS n 
rf networks may be operated independently. 

a. Intranetwork Qmununications. 

Intranetwork communications involve the exchange of messages between 
user ^sterns that subscribe to a common OTCIXS n rf network. OTCIXS n will directly 
supports intranetwork communications for the user system Tactical Data Processors 
(TDPs) shown in Table 1-1. OTCIXS n intranetwork coimectivities are illustrated in 
Figure 1-1. 

b. Internetwork Crnnmunications. 

Intemetworir coimnunications involve the exchange of messages between a 
user ^stem that subscribes to an OTCIXS II rf network and a user system; 
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1. Ashore 


2. That subscribes to a different OTCKS11 if network 

3. That subscribes to a TADIXS or first generation OTCEXS rf netwoik. 
Table 1-1. OTCKS n TDPs Communicating Intranetwork 


OTCKS n USER SYSTEM TDP 

LOCATION 

Tomahawk Weapons Control System (TWCS) 

Surface Ship 

Naval Communications Telecommunications Stations (NCTS) 

Shore/Surface Ship 

Naval Communications Telecommunications Station (NCTAMS) 

Shore 

Global Command & Control System - Maritime (GCCS-M) 

Sur&ce Ship 


Shore 

Joint Operational Tactical System (JOTS) 

Surface Ship / Shore 


OTCKS n will operate in conjimction with TADKS-A to support the internetwork 
communications requirements of the user system TDPs shown in Table 1-2. OTCKS 11 
internetwork connectivity is illustrated in Figure 1-2. Intemetworking capabilities 
provided by TADKS Gateway Fadlities (TCH^s), AN/USQ-64(V)9, implement the 
worldwide connecti^aty illustrated in Figure 1-3. TGFs are located at Naval Computer 
and Telec ommuni cations Area Master Stations (NCTAMS) at Norfolk, Virgima 
(NCTAMS LANT), Wahiawa, Hawaii (NCTAMS EASTPAC), Finegayan, Guam 
(NCTAMS WESTPAC), andBagnoli, Italy (NCTAMS MED), and at Naval Computer 
Telecommunications Station (NCTS) Stockton, California. 

2. OTCKS n Subscriber Equipment Suites. 

Three OTCKS n subscriber equipment suites need be implemraited: surface ^p. 
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submarine, and shore. These equipment suites are described in the following 
subparagraphs. 

Table 1-2. TADDCS A/OTCDCS11 TDPs Communicating Internetwork 


TADIXS-A USER SYSTEM TDP 

LOCATION 

Naval Communications Telecommunications Station 

(NCTAMS) 

Shore 

Ocean Surveillance Information System (OSIS) 

Shore 

hfission Data Distribution System (MDDS) 

Shore 


a. Surface Ship. 

The surface ship OTCIXS n configuration can fimction as the Network 


Control Station (NCS) or a subscriber unit of an OTCIXS II rf network (either DAMA or 
non-DAMA mode) and supports message exchange for the TWCS, FDDS, and teletypes. 
Figure 1-4 illustrates the surface ship configuration. In the surface ship configuration, the 



Figure 1-1. OTCIXS n Intranetwork Connectivity 











OTCIXS n subscriber equipment suite consists of the following components; 


(1). ON-143(V)6AJSQ and/or ON-143(V)14/USQ Interconnecting 
Groups, including Control Indicator (Cl), a human control interface (HCI) device, and 
the necessary software to enable it to ftmction as an OTCIXS n Lmk ControllCT. The 
ON-143(V)6 of (V)14 hosting the OTCIXS n Link Controller also supports access to a 


TADEXS-A rf network. The TADIXS-A link protocols are capabilities outside the scope 
of this thesis. 





1 

OSIS 

Mnns 

STT 

JOTS 





ADJACENT TFG ADJACENT TFG 


Figure 1-2. OTCIXS n Internetwork Connectivity 
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Figure 1-3. OTCIXS n Worldwide Connectivity by TADIXS 

(2) . KG-84A Cryptographic Unit. 

(3) . AN/UGC-136BX or AN/UGC-77 Teletype 
b. Submarme. 

The submarine OTCIXS n configuration fimctions as a subscriber unit of a 
Non-DAMA OTCIXS n rf network. The submarine OTCIXS 11 configuration supports 
message exchange for the CCS MK-1 / MK-2 and teletype. Figure 1-5 illustrates the 
submarine configuration. In the submarine configuration, the OTCIXS n subscriber 
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equipment suite consists of the following conq)onents; 

(1) . ON-143(V)6/USQ or ON-143(V)14/USQ Interconnecting 
Group, including Cl, with the necessary software to enable it to ftmction as an OTCIXS n 
Link Controller. The ON-143(V)6 hosting the OTCIXS 11 Link Controller also supports 
access to a TADIXS-A or Submarine Satellite Information Exchange Subsystem (SSIXS) 
rf network. SSIXS capabilities are, however, outtide the scope of this thesis. 

(2) . KG-84A Cryptographic Unit. 

(3) . AN/UGC-136AX or ANAJGC-77 Teletype. 
c. Shore. 

The shore OTCIXS n configuration fimctions as dther NCS or a 
subscriber unit of the OTCIXS 11DAMA or Non-DAMA rf network. It fimctions under 
the control of the TADIXS Gateway Processor (TGP) and supports the relay of subscriber 
messages between difierent rf networks or between user systems ashore and subscribers to 
the OTCIXS n rf network it accesses. Ashore TDPs supported by the OTCIXS n Link 
Controller are the TDDS, Shore Targeting Terminal (STT), Joint Operational Tactical 
System (JOTS), Global Command and Control System - Maritime (GCCS-M), Ocean 
Surveillance Information System (OSIS), OSIS Baseline Upgrade (OBU), and MODS. 
Figure 1-6 illustrates the shore configuration. 

In the shore configuration, the OTCIXS n subscriber equipment suite consists of the 
following components: 

(1). ON-143(V)6/USQ Interconnecting Group, including Cl, with 
the necessary software also functions as the shore OTCIXS n Link Controller. 
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OTCDCSI cotmminicattons is via single WSC-3 (non-DAMA) 

TADDCS A CknsmunicatioQS is via WSC-5 / TD-i271/BU (DAMA unit) 
OTCDCS n can be via WSC-3/5 and/or TD-1271-BU DAMA unit 
(DAMA & non-DAMAmode) 



Figure 1-4. Surface Ship Configuration with OTCEXS n 
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Figure 1-5. Submarine Configuration with OTCIXS n 
(2). KG-84A Cryptographic Unit. 

3. Subscriber Identification. 

Each OTCIXS II subscriber is identified by a unique Subscriber Identification 


(SID) number which may range fi’om 0001 to 9999. The OTCIXS n accommodates the 
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following address types: 

a. Discrete. A discrete SID is the unique number assigned to a specific surface 
ship, submarine, or shore &cility. 

b. Collective. A collective SID is the unique number assigned to a group of fleet 
units or commands. Provisions exist for two types of collective addresses. These are: 

1. Organizational. Organizational collectives contain spedfic fleet 
platforms or shore commands. The composition of an organizational collective may 
change with time. 

2. Regional. Regional collectives are associated with a specific satellite 
coverage area and effectively constitute an"... all subscribers in a geographic region..." 
address. 

a. Subscriber Data. 

The OTCIXS n facilitates the timely exchange of subscriber messages. 
The OTCIXS 11 neither depends upon nor analyzes the information content of such 
messages but employs information contained in spedally formatted "header" preambles 
which are attached to every message transferred over the satellite link. To support the 
internetwork routing of messages by TADIXS-A, OTCIXS n messages must conform to 
the requirements imposed by Volume I of the TADIXS Interface Design Spedfication 
(IDS). 
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Figure 1-6. OTCIXS n Shore Gateway Configuration 
b. NonscheduJed and Scheduled Broadcasts. 

The OTCIXS n includes operating features needed to support both 
Nonscheduled and Scheduled broadcasts. Nonscheduled Broadcasts occur randomly and 
are independent of specific preplanned instants in real time. Nonscheduled broadcasts 
may be executed from any OTCIXS n configuration. Scheduled Broadcasts occur only at 
preplanned instants in real time. To define and execute a scheduled broadcast fi'om a 


11 









surfece ship configuration the OTCIXS n Link Controller receives all information 
required to implement that broadcast from the OTCIXS n operator via the attached Cl. 
This information includes the number of times transmission is to occur and the times in 
each hour, expressed in quarter hours and minutes past the quarter hour, at vdiich each 
transmission is to conimence. To define and execute a scheduled broadcast from a shore 
configuration, the OTCIXS n Link Controller receives all information required to 
implement that broadcast from its interfaced TGP. Scheduled broadcasts cannot be 
defined or executed from a submarine configuration. 

4. Message Identification. 

Each subscriber to the OTCIXS n rf network assigns a 16-bit identifier to each 
message it transmits on that network. This identifier and the transmitting subscriber's SID 
provide unique message identification for message accountabilhy. 

a. Message Length. 

OTCIXS n accommodates messages up to 10,103 bytes in length. 
Messages exceeding the maximum length must be divided by the ori^nator, into multiple 
parts, each part not to exceed the maximum length. OTCIXS n treats each part of a 
multi-part message as a separate message. The user computer ^stem is responsible for 
s^menting, reassembling, and sequencing the parts of a multi-part message. 

b. Message Precedence. 

The OTCIXS II recognizes Flash and Immediate precedence levels. Flash 
precedence messages always receive transmission priority over immediate precedence 
messages. Flash precedence messages always receive transmission priority over scheduled 
broadcast messages. Scheduled broadcast messages receive transmission priority over 
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nonscheduled Immediate precedence messages, 
c Networti ControL 

A subscriber designated as the Net Control Station (NCS) coordinates the 
use of the OTCIXS n network. All surface ship and shore sites will be capable of 
flsjaiming the NCS fimction. The NCS receives, queues, and acknowledges receipt of 
subscriber access requests. Queued requests will be serviced in accordance with a 
first-come, first-served by precedence networic server discipline. The NCS will assign 
service and assign transmission times to all Flash requests, then scheduled Immediate 
requests, and finally nonscheduled finmediate requests. Transmission of subscriber data 
occursonly when authorized by the NCS. Once a subscriber has been authorized by the 
NCS to transmit its message, the subscriber will commmce message transmission. Once 
message transmission has commenced, the transmission will not be pre«npted by other 
message transmissions r^ardless of the precedence of the messages involved. 

C. CONTENT DESCRIPTION. 

The remainder of this document consists of the following sections and appendkes: 

1 . Section n. Applicable Documents, provides a list of documents applicable to 
the preparation of this document. 

2. Section HI, Intaface Summary Cross-Index, provides a cross-index of agnals 
transferred between OTCIXS n subscribers. 

3. Section TV, Signal D^nitions List, defines the usage and effect of each signal 
transferred between OTCIXS n subscribers. 

4. Section V, Narrative Signal Flow Table, describes each interface agnal as well 
as the interactions and interrelationships among the signals. 


13 



5. Section VI, Communication Controls and Conventions, defines and describes 
the communication control responsibilities and conventions for each of the OTCEXS n 
subscribers. 

6. Section VII, Data Unit Descriptions, provides a detailed description of the data 
unit formats. This section will incorporate material specified by DI-E-2135. This 
interface t 5 ^e lends itself to the combined section and a clearer representation of the 
material is accomplished. 

7. Appendix A, List of Acronyms and Abbreviations, provides a list of acronyms 
and thdr respective definitions. 

8. Appendbc B, Cyclic Redundancy Check G«ieration, fists and describes the 
algorithm bang used to genaate the Cyclic Redundancy Check. 

9. Appendix C, OTCIXS11 Simulation Results. 

10. Appoidix D, OTCIXS II Model Simulation Setup File Format. 

11. Appendix E, Setup File Standard Values. 
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II. INTERFACE SUMMARY CROSS-INDEX 


A. GENERAL 

This section provides a tabular index to sections IV (Signal Definition List), V 
(Narrative Signal Flow Table), and VII (Data Unit Descriptions) for each signal passed 
between members of an OTCIXS H network. It also lists and provides a cross-reference 
index (Table 2-1) to sections IV, V, and VH for the Physical layer signals employed by the 
OTCIXS n Link Controllers interfecing with; 

1. KG-84A cryptographic device 

2. TD-1271B/U DAMA multiplexer 

3. ANAVSC-3/5 transceiver. 

B. SIGNAL SUMMARY CROSS-INDEX - NET CONTROL STATION TO 
SUBSCRIBER 

Table 2-2 list the signals passed fi'om the OTCIXS n Net Control Station (NCS) 
to the OTCIXS 11 subscribers and provides a cross-reference index to sections IV, V, and 

vn. , 

C. SIGNAL SUMMARY CROSS-INDEX - SUBSCRIBER TO NET CONTROL 
STATION. 

Table 2-3 list the signals passed from the OTCIXS n subscribers to the OTCIXS 
n NCS and provides a cross-reference index to sections IV, V, and VH. 

D. SIGNAL SUMMARY CROSS-INDEX - SUBSCRIBER TO SUBSCRIBER 
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Table 2-4 list the signals passed between OTCIXSII subscribers and provides a 


cross-reference index to sections V, V, and VII. 

Table 2-1. Physical Layer Signal Cross-Index 


SIGNAL NAME 

PAGE NUMBER INDEX TO 


SIGNAL 

NARRATIVE 

DATA UNIT/ 


DHTNinON 

SIGNAL 

MESSAGE 


LIST 

FLOW TABLE 

DESCRIPTION 

1. Channel Busv 

24 

45 


2. Crvpto Alarm Indicate 

24 

49 

„ 

3. Crvnto Alarm Reset 

24 

49 


4. Crvpto PREP 

24 

42&46 

„ 

5. External Transmit Reauest 

24 

46 

_ - 

6. Kevline 

25 

42 

_ 

7. Receive Data 

25 

45&48 

„ 

8. Receive Data Black 

25 

45&48 


9. Receive Data Red 

25 

45&48 


10. Sienal Acauired fSIGACO) 

25 

48 

„ 


25 

46 


12. Transmit Data 

26 

44&47 

_ 

13. Transmit Data Black 

26 

44&47 

_ 

14. Transmit Data Red 

26 

44&47 


15. Black Transmit Clock 

26 

1 


16. Black Receive Clock 

26 



17. Black Receive/Transmit Clock 

27 



18. Red Gated Clock 

^ 27 

— 
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Table 2-2. NCS to SubscribCT Signal Cross-bidex 



PAGE NUMBER INDEX TO 


1. Data Link Layer Packet 

a. Count 

b. Cyclic Redundant Check (CRC) 

c. End 

d. Information _ 

2. Net Control Block (NCB) 

Transmission Unit (TU) 

a. Component Identification (CID) 

b. Copy 

c. Flash Slots 

d. Granted Subscriber ID (GSID) 

e. Hits 

f. Hours 

g. Immediate Slots 

h. bfinutes 

i. Mode 

j. Net Control Station (NCS) Link 
Access Queue 

k. Net Control Station (NCS) Link 
Access Queue Size 

l. Net Control Station (NCS) SID 

m. RATS Type 

n. Scheduled Broadcast Status (SB 
STATUS) 

o. Seconds 

p. STUl Acknowledge 

q. STU2 Acknowledge 

r. STU3 Acknowledge 

s. Time Checksum 

t. Transmit Count (XMTT CT) 

u. Window Size 


SIGNAL 

DEFINITION 

LIST 


27 


NARRATIVE 
SIGNAL FLOW 

tabie: 



DATA UNIT/ 
MESSAGE 
DESCRIPTION 


135 










Table 2-2. NCS to Subscriber Signal Cross-Index (cont.) 


SIGNAL NAME 

PAGE NUMBER INDEX TO 


SIGNAL 

DEFINmON 

LIST 

NARRAITVE 
SIGNAL FLOW 
TABLE 

DATA UNIT/ 
MESSAGE 
DESCRIPTION 

3. Network Message 

31 

— 

134 

a. Block Check Sequence (BCS) 

b. Broadcast Sequence Number ^SN) 
a. c. Transport Messaee 




4. Subscriber Transmission Unit (STU) 

32 

57 

128 

a. Component Identification (CID) 

b. Copy 

c. Message Pointer Block 

d. Mode 

e. More 

f. Network Message 

g. Precedence (PREC) 

h. Reservation (RESV) 

i. Subscriber Identification (SID) 

j. Transmit Count (XMTT CT) 

k. Transmit h^ute 
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Table 2-3. Subscriber to NCS Signal Cross-Index 


SIGNAL NAME 

PAGE NUMBER INDEX TO 

SIGNAL 

DEFINrnON 

LIST 

NARRATIVE 
SIGNAL FLOW 
TABLE 

DATA UNIT/ 
MESSAGE 
DESCRIPTION 

1. Data Link Layer Packet 

a. Count 

b. Cyclic Redundanq? Check (CRC) 

c. End 

d. Information 

27 


135 

2. Network Message 

a. Block Check Sequence (BCS) 

b. Broadcast Sequence Number (BSN) 

c. Transport Message 

34 


134 

3. Reservation Request TU (RRTU) 

a. Component Identification (CID) 

b. Copy 

c. Mode 

d. Retry Coxmt 

e. Subscriber Identification (SID) 

£ Transmit Count (XMIT CT) 
g. Transmit Minute 

34 

54 

125 

4. Subscriber Transmission Unit (STU) 

a. Component Identification (CID) 

b. Copy 

c. Message Pointer Block 

d. Mode 

e. More 

£ Network Message 

g. Precedence (PREC) 

h. Reservation (RESV) 

i. Subscriber Identification (SID) 

j. Transmit Count (XMIT CT) 

k. Transmit Minute 

35 

57 

128 
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Table 2-4. Subscriber to Subscriber Signal Cross-Index 


SIGNAL NAME 

PAGE NUMBER INDEX TO 


SIGNAL 

DEHNITION 

LIST 

NARRATIVE 
SIGNAL FLOW 
TABLE 

DATA UNIT/ 
MESSAGE 
DESCRIPTION 

1. Data Link Layer Packet 

27 

— 

135 

a. Count 

b. Cyclic Redundancy Check (CRC) 

c. End 

d. Information 




2. Network Message 

37 

— 

134 

a. Block Check Sequence (BCS) 

b. Broadcast Sequence Number (BSN) 

c. Transport Messa&e 




3. Subscriber Transmission Unit (STU) 

37 

57 

128 

a. Component Identification (CID) 

b. Copy 

c. Message Pointer Block 

d. Mode 

e. More 

f. Network Message 

g. Precedence (PREC) 

h. Reservation (RES\0 

i. Subscriber Identification (SID) 

j. Transmit Count (XMIT CT) 

k. Transmit hfinute 
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III. SIGNAL DEFINITION LIST 


A. GENERAL 

This section defines the phyacal interfiice signals used by the OTCIXSII Link 
Controllo- to control and monitor the KG-84A cryptogrq)hic unit, TD-1271B/U DAMA 
multiplKtCT, and ANAVSC-3/5 transceiver. It also defines the agnals exchanged between 
members of an OTCIXS n netwoik. 

1. Protocol Layers. 

The interfece as described in this document conasts of sevaal protocol layers: 

a. Phyacal Layer - The Physical Layer are the signals that the OTCIXS n software 
generates to control the OTCIXS n equipment or receives to monitor the OTCIXS n 
equipment. Signals discussed are the signals between the ON-143(V)6 or ON-143(V)14 0iere 
after referred to as the OTCIXS n Link Controller) and: 

1. KG-84A ayptographic device. 

2. TD-1271B/U DAMA multiplexer. 

3. ANAVSC-3/5 transcdver. 

b. Data T.ink Layer - The Data Link Layer comprises the agnals used to ensure an 
error-free transfer of information between OTCIXS II subscribers. 

c. Network Layer - The Network Layo" comprises the agnals to control the allocation 
of the netwoik resources among the OTCIXS n subscriba^ and the vehicle for transporting 
OTCIXS n subscriber to subscriber transactions. 

2. General Definitions. 

General definitions pertinent to the discusaon of this interface are: 
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a. Broadcast Sequence Number (BSN) - the BSN is a 16-bit quantity asagned to a 
network message by the subscriber that originates an OTCIXS n transmission BSNs shall be 
assigned sequentially so that missed messages can be detected by a gap in the BSNs recdved 
from a subscriber. 

b. Transmission Unit (TU) - the TU is the entity that is transferred over the OTCIXS 
n network. All data items, network control and messages, shall be transmitted over the 
OTCIXS n network in TUs. 

c. Net Control Station (NCS) - an OTCIXS n subscriber that controls the allocation 
of transmisaon time among the OTCIXS n network members. 

d. Link Access Queue (LAQ) - a quoie maintained by the NCS that identifies each 
OTCIXS n subscriber that has requested network transmission time. The queue shall be 
ordered first in, first out (FIFO) by precedence. 

e. Net Cycle - an OTCIXS n net rycle is the time from the transmisaon of a Net 
Control Block (NCB) by the NCS to the next transmisaon of a NCB by the NCS. There are 
two types of net cycles; Idle and Busy. An idle cycle is a net cycle where no subscriber 
transmissions occur. Abusy cycle is a net cycle where a subscriber transmisaon occurs. Each 
net cycle consists of time slots, as follows; 

1. Control Time Slot (CTS) - provides the information to control the operation 
of the network. NCBs are transmitted in the CTS. 

2. Random Access Time Slot (RATS) - provides the period for OTCIXS n 
subscribers to requea transmission time. Reservation Requea (RR) TUs (RRTUs), containing 
subscriber requests for net time, are transmitted in the RATS. 

3. Subscriber Transmisaon Time Slot (STTS) - provides the period for 
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subscribers to transmit network messages. Subscriber TUs (STUs), containing network 
messages, are transmitted in the STTS. 

f. Network Message - the entity transferred by the OTCIXS H protocol including 
sequencing to provide the mechanism for the detection of missed messages and a Block Check 
Sequence (BCS) used in error detection. 

g. Request Slot (RS) - a period in a RATS where a subscriber is pamitted to request 
net time from the NCS. There are two types of request slots: Immediate and Flash. 

h. Subscriber Identification (SID) - the SID uniquefy identifies a subscriber in the 
communication networks accessed by TADDCS (which includes OTCIXS D). 

i. . Transport Message - the subsoiber-to-subscribCT infijrmation entity, that is, 
formatted computer-to-computo’ data, teletype, and system control messages. 

B. PHYSICAL LAYER SIGNAL DEFINITION LIST. 

Physical Layer interface agnals enqiloyed by the OTCIXS n Link Controller to control 
and monitor the KG-84A ayptographic unit, TD-1271B/U DAMA multiplexer, and the 
AN/WSC-3/5 transcdver are defined in Table 3-1. 

C. DATA LINK LAYER SIGNAL DEFINITION LIST. The Data Link interfece signals 
enqjloyed by the OTCIXS n Link Controller are defined in Table 3-2. 

D. NETWORK LAYER SIGNAL DEFINITION LIST. The Network Layer intCTfece 
si gnals ai^loyed by the OTCIXS II Link Controller are grouped into three cat^ories: 

a. Net Control Station (NCS) to Subscriber. Signals transferred from the OTCIXS n 
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NCS to OTCDCS n subscribers are listed and defined in Table 3-3. 

b. Subscriber to Net Control Station. Signals transferred fi’om OTCDCS n subscribers 
to the OTCEXS n NCS are listed and defined in Table 3-4. 

c. Subscriber to Subscriber. Signals transferred between OTCIXS n subsoibers are 
listed and defined in Table 3-5. 

Fields containing critical data items in these data units are triply encoded. Triply 
encoded fields consist of the contents of the field itselj^ the contents of die field in the one's 
compl^ent form, and the contents of the field Excluave ORed with a tnnary pattern of 
alternating ones and zeros commensurate with the width of the field. A match of at least two 
of these fields will validate the contents of the field. 


Table 3-1. Phyacal Layer Signal Definition List 


SIGNAL 

DEFDSimON 

1. Channel Busy 

A signal from the AN/WSC-3/5 to tiie OTCIXS n Link Coitroller 
to indicate that a signal is presort. It is received on Channel A bit 4, 
of the Parallel hqriit/ Output (PIO) on frie Black Dynamic Additive 
Receiver/ Transmitter (DARI) in the OTCIXS II T^mk Controller. 

This sianal is used only in Non-DAMA mode ooerations. 

2. Crypto Alarm Indicate 

A signal fr-omihe crypto to tire OTCIXS n Link ControDer to 
indicate that it is in die alarm state, ft is received on channel B, bit 2, 
of the PIO on the Crypto DART in the OTCIXS H Link Controller. 
This signal is sent by the KG-84A as Red Alarm hidicate (RH)-AI). 

3. Crypto Alarm Reset 

A signal from the OTCIXS n Lmk Controller to the crypto to clear 
the alarm state, ft is sort on channel B, bit 6, ofthe PIO on die 

Crypto DART in the OTCIXS n Link Controller. This signal is 
received bv die KG-84A as Remote Standby Red tRP-STBYR) 

4. Crypto PREP 

A signal from the OTCIXS n Lurk Crxitroller to the crypto to put the 
crypto into die transmit mode and resynchronize it. ftissarton 
channel B, bit 7, of die PIO on the Crypto DART in the OTCIXS II 
link Controller. This signal is received bydieKG-84A as 
Synchronize Command Transmit (SYNC-CMD-TXl 

5. External Transmit 
Request 

Signal sent by the OTCIXS n link Controller to the TD-1271B/U 
multiplexer to transmit a TU overthe OTCIXS n network, ft is sent 
aa channel B, bit 6 and 7, of the PIO cm Black Dart in the OTCIXS 
n Link Controller. This signal is used only in DAMA mode 
operaticms. 
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Table 3-1. Physical Layer Signal Definition List (cont.) 


SIGNAL 

DEFINITION 

6. Keyline 

Signal sent by the OTCIXS n Link Controller to the 
ANAVSC-3/5 transcdK^er to transmit a TU over the OTCIXS 
n network. It is sent on channel B, bit 6 and 7, of the PIO on 
the Black DART in the OTCIXS n Link Controller. This 
agnal is used only in Non-DAMA mode operations. (In 
DAMA mode operations, the TD-1271B/IJ performs 
transceiver kev fimctionsL 

7. RecdveData 

Serial data recaved by the black side of the OTCIXS n Link 
Controlla fi'om the AN/WSC-3/5 (Non-DAMA mode 
operations) or TD-1271B/U (DAMA mode operations). The 
data is clocked by an internally generated clock that is 
synchronized to the external clock genaated by the sending 
device. 

8. Recdve Data Black 

Serial data sent to the crypto fi’om the black side of the 
OTCIXS n Link Controlla. Data is clocked by an intemalfy 
genaated clock that is synchronized to the extanal clock 
genaated by the AnAVSC-3/5 transcdva (Non-DAMA mode 
operation) or by the TD-1271BAJ multiplexa (DAMA mode 
operations). This signal is recdved by the KG-84A as 

External Recdve Cvohaed Text (ERCTl. 

9. Recdve Data Red 

Serial data received fi’om the crypto by the red side of the 
OTCIXS n Link ControUa. Data is clocked by an internally 
genaated clock that is synchronized to the external dock 
generated by the ANAVSC-3/5 transcdva (Non-DAMA 
mode operations or by the TD-1271B/U muMplexa (DAMA 
mode operations). This agnal is sent by the KG-84A as 
Recdve Didtal Plain Text (RX-DPT). 

10. Signal Acquired 
(SIGACQ) 

A signal firom the TD-1271B/U multiplexa to the OTCIXS II 
Link ControUa to indicate that a sigiwl is present. It is 
recdved on channel A, bit 4 of the PIO on the Black DART in 
the OTCIXS n Link ControUa. This agnal is used only in 
DAMA mode ooaations. 


11. Slot Time hferk Signal recdved by the OTCKS n Link Controller from the 

(STM) TD-1271B/U to provide DAMA timing. It is received on 

channel B, bit 4, of the PIO on both the Crypto and Black 
DART in the OTCDCS n Link Controller. Signal is received 
every 1.38667 seconds to provide synchronization with the 
DAJ^ timeslot. Signal is used only in DAMA mode 
operations. 
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Table 3-1. Physical Layer Signal Definition List (cont.) 


SIGNAL 

DEFBSimON 

12. Transmit Data 

Serial data sent by the black ade of the OTCIXS n Link 
Controller to the ANAVSC-3/5 (Non-DAMA mode 
operations) or the TD-1271B/U (DAMA mode operations). 

The data is clocked by an internally generated clock that is 
synchronized to the external clock generated by the recdving 
device. 

13. Transmit Data Black 

Serial data received by the black side of the OTCIXS n Link 
Controller fi’om the ciypto. The data is clocked by an 
internal^ generated clock that is synchronized to the external 
clock gaierated by the ANAVSC-3/5 transcdver (Non- 
DAMA mode operations) or by the TD-1271B/U multiplexer 
(DAMA mode opCTations). ThisagnalissentbytheKG-84A 
as External Transmit Cvphered Text (ETCT) 

14. Transmit Data Red 

Serial data sent by the red side of the OTCIXS n link 

Controller to the crypto. The data is clocked by an internally 
generated clock that is synchronized to the external clock 
gaierated by the AN/WSC-3/5 transceiver (Non-DAMA 
mode operations) or by the TD-1271B/U multiplexer (DAMA 
mode operations). This signal is received by the KG-84A as 
Transmit Dimtal Plain Text fTX-DPTY 

15. Black Transmit Clock 

This signal is generated by the AN/WSC-3 or TD-1271B/U. 

It pro\ides transmit data bit interval timing information to the 
OTCIXS n Link Contorller. It is connected to connector J1 
pin #70. The signal is then routed throu^ the Radio 

Interfiice Board (RIB) to the Black DART board. The RIB 
card allows inversion and source selection of the transmit 
clock signal. During a transit sequence, the Black DART 
software samples the transition of the transmit clock on PIO 
bit B2. It then phase-locks the CTC 0 timer to provide a 
stable Black Transmit Clock to the KG-84 A. 

16. Black Receive Clock 

This signal is generated by the AN/WSC-3 or TD-1271B/U. 

It provides receive data bit intm^al timing information to the 
OTCIXS n Link Controller. It is coimected to connector J1 
pin # 76. The signal is th^ routed through RIB to the Black 
DART board. The RIB card allows inversion and source 
selection of the receive clock agnal. During a recdve 
sequence, the Black DART software samples the transition of 
the recdve clock on PIO bit B3. It then phase-locks the CTC 

0 timer to provide a stable Black Receive Clock to the KG- 
84A device. 
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Table 3-1. Phyacal Layer Signal Definition List (cont.) 


SIGNAL 

DEFINITION 

17. Black 

Recdve/Transmit Clock 

This signal is generated by the CTC 0 on the Blax^ DART in 
the OTCEXS n Link Controller. The agnal is output fi-om 
connector J9 pin # T on the rear connector panel. It provides 
recdve and transmit bit interval timing for the KG-84A 
cryptographic units. It should be coimected to the n^ative 
clock inputs on the KG-84A cryptogr^hic device. This signal 
is a software phase-locked version of the Radio transmit and 
recdve clocks. 

18. Red Gated Clock 

This agnal is generated by the KG-84A cryptographic units. 

The KG-84A sends this signal on J3 pin 20, which is the 
recdve clodc's n^ative ou^ut. The KG-84A ciyptos do not 
eate the recdve clock durins a receive run-uo sequence. 


Table 3-2. Data Link Layer Signal Definition Lia 


SIGNAL 

DEFINITION 

1. Data Link Layer Packet 

The Data T -ink entity for a Network message. Provides error 
detection mechanism for messages. 


Tndiratfts the number of bytes in the INFORMATION field. 

a. Count 

Provides an error detection code for the Data Link Packet as 

b. Cyclic Redundanqr 
check (CRC) 

described in appendix B. Calculated over the COUNT, 

END, and INFORMATION fields of the packet. 

Identifies whether this is the last packet of a multipacket 
sequence. 


Part or all of a network message. 

c. End 


d. Information 
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Table 3-3. NCS to Subscriber Signal Definition List 


SIGNAL 

OPERATION 

1. Net Control Block (NCB) 
Transmission Unit (TU) 

A TU transmitted by the NCS to control the 
allocation of subscriber accesses to the 

OTCDCS n network. The NCB TU infonhs 
the OTCIXS n subscribers of the current net 
operating configuratioa 

a. Component Identification (CID) 

Identifies the TU as an NCB TU. 

b. Copy 

Identifies the number of times, including this 
transmisaon, that this NCB has been 
transmitted in the current net cycle. 

c. Flash Slots 

Identifies the mnnber of RSs in the current net 
cycle that are assigned to Flash message RRs. 
\Wthin the RATS, these slots precede those 
asagned to Immediate message RRs. This field 
is ignored xmless the RATS TYPE field 
indicates that a Normal RATS is present in the 
current net cycle. 

d. Granted Subscriber Identification 
(GSID) 

Identifies the OTCIXS n subscriber that has 
been assigned transmission time in the current 
net cycle. 

e. Hits 

Indicates the minimum number of net cycles, 
within the window specified by the WINDOW 
SIZE field, in which a net member mua recdve 
at leaa one message for transmission in ordCT 
to predict a network service requirement. 

Choices are 2,3,4, and 5 net cycles. 

f Hours 

Identifies the hours component of the current 
network time as maintained by tire NCS. 
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Table 3-3. NCS to Subscriber Signal Definition List (cont.) 


SIGNAL 

OPERATION 

g. Immediate Slots 

Identifies the number of RSs in the current net 
cycle that are asagned to Immediate message 

RRs. Within the RATS, these slots follow 
those asagned to Flash message RRs. This 
field is ignored unless the RATS TYPE field 
indicates that a Normal RATS is present in the 
current net qrcle. 

h. Minutes 

Identifies the minutes component of the current 
network time as maintained by the NCS. 

i. Mode 

Indicates the acti^^ schedules for this net 
cycle. Posable activities are: 


a. Nonscheduled transmisaon of Flash 
precedaice STU 

b. Nonscheduled transmisaon of Immediate 
precedence STU 

c. Scheduled broadcast transmisaon of STU 

d. No STU transmisaon 

j. Net Control Station (NCS) Link 
Access Queue (LAQ) 

Idoitifies pending requests for link time 
asagnment for STU transmissions. Organized 
on a first-come, first-serve (FCFS) within 
preced«ice basis, the entries in this queue 
identify: 


a. Requesting subscriber 

b. Type of service requested 

c. Number of transmissions requested 

d. Minute at which transmissions are to 
commence (scheduled broadcasts only). 
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Table 3-3. NCS to Subsaiber Signal Definition List (cont.) 


SIGNAL 

OPERATION 

k. Net Control Station (NCS) Link 
Access Quaie (LAQ) Size 

Indicates the number of entries in the NCS 

LAQ (i.e., the number of pending service 
requests by net subscribes). 

1. Net Control Station (NCS) 

SubsCTiber Identification (SBD) 

Identifies the OTCIXS n subscribe that is 
performing the NCS fimction. 

m. RATS Type 

Spedfies the characteristics of the RATS 
supported in this net tycle are as followings; 


a. A normal RATS is present in this q/'cle 

b. This is the first net cycle of an extended 
RATS 

c. This is an intermediate ne cycle of an 
extended RATS 

d. This is the final ne cycle of an extended 
RATS. 

a Scheduled Broadcast Status 
(SB STATUS) 

Indicates if scheduled broadcasting is beng 
performed in the current ne cycle and, if not, 
whether scheduled broadcasting previously 
requested for the current ne cycle has been 
preempted. 

0 . Seconds 

Identifies the seconds componait of the current 
network time as maintained by the NCS. 

p. STU1 Acknowledge 

Provides an acknowledgment to the OTCIXS n 
subscriber that transmitted an STU one ne 
cycle prior to the current one. 

q. STU 2 Acknowledge 

Provides an acknovdedgment to the OTCIXS n 
subscribe that transmitted an STU two ne 
cycles prior to the current one. 

r. STU 3 Acknowledge 

Provides an acknowledgment to the OTCIXS n 
subscribe that transmitted an STU three ne 
cycles prior to the current one. 
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Table 3-3. NCS to Subscriber Signal Definition List (cont.) 


SIGNAL 

OPERATION 

s. Time Checksum 

hidicates the checksum for the Hours, Minutes, 
and Seconds fields. Used to validate the time 
and to update the net time when validation is 
possible. 

t. Transmit Count (XMIT CT) 

Indicates the number of times the subscriber 
designated by the GSID field is to transmit its 
STU. 

u. Window Size 

Indicates the number of net cycles to by used by 
network service in predicting network service 
requirements. Choices are 12,16,20, and 24 
net cvcles. 

2. Network Message 

Provides the vehicle for transferring a Transport 
Message. Also provides for sequencing, to 
permit identification of missed messages, and 
error detection. 

a. Broadcast Sequence Number (BSN) 

Identifies the sequence number of the transfer. 

All transfers are sequentially mimbered fi’om a 
spedfic subscriber to pamit recdving stations 
to recognize missed messages. 

b. Transport Message 

The actual message at the Transport layer that 
is being transferred between OTCDCS n 
subscribers. The fijrmat of the Transport Layer 
Message is as defined in the TADIXS IDS, 
Volume I. 

c. Block Check Sequence (BCS) 

Provides an error detection code for the 
Transport Layer message as described in 
Appendix B. Calculated over all bytes of the 
Transport Message field. 
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Table 3-3. NCS to Subscriber Signal Definition List (cont.) 


SIGNAL 

OPERATION 

3. Subscriber Transmission Unit (STU) 

Provides the transmission aitity for the 

Transport layer entities (e.g., formatted 
computa’-to-computer data and teletype 
messages). 

a. Con^nent Identification (CID) 

Identifies the TU as an STU. 

b. Copy 

Identifies the numba of times, including this 
transmission, that this STU has been transmitted 
in the current net cycle. 

c. Message Pointer Block 

Identifies how many network messages ae 
present in the STU and, for each such message, 
a pointa to the start of the message in the STU. 
Also contains a Pointa Check Sequence (PCS), 
calculated in accordance with Appendbc B, to 
ensure the validity of the message pointas. 

d. Mode 

When the Reservation (RESV) field indicates 
that this STU contains a piggybacked service 
request, this field identifies the type of request 
being made. Possible service requests ae; 


a. Nonscheduled transmission of Flash 
precedence STU required 

b. Nonscheduled transmisrion of Immediate 
precedence STU required 

c. Scheduled broadcast transmission of STU 
required. 

e. More 

Indicates if additional service is required for 

STU transmisaon on the current broadcast 
schedule (i.e., the current scheduled broadcast 
cannot be completed in a single STU). 

f. Network Message 

Contains a Transport Message and a BCS. 

Also identifies the BSN for the transaction. 

g. Precedence (PREC) 

Identifies the precedence level of the STU as 
dther Immediate or Flash. 
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Table 3-3. NCS to Subscriber Signal Definition List (cont.) 


SIGNAL 


OPERATION 


h. Reservation (RESV) 


Indicates whether this STU contains a 
piggybacked service request. 


i. Subscriba’Identification (SID) 


Identifies the OTCKS n subscriba that 
originated the STU transmissaon. 


j. Transmit Count (XMIT CT) 


k. Transmit Minute 


When the RESV field indicates that a 
f Mggy backed RR is present, this field indicates 
the numba of times the STU refaenced by that 
request is to be transmitted. 

When the RESV field indicates that a 
pi ggy backed service request for a scheduled 
broadcast is present, this field indicates the 
minute, wifirin the hour, at which that broadcast 
is to occur. 
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Table 3-4. Subscriber to NCS Signal Definition List 


SIGNAL 

DEFBSTnON 

1. Network Message 

Provides the vehicle for transferring a Transfer 
Message. Also provides for sequencing, to 
permit identification of missed messages, and 
error detection. 

a. Broadcast Sequence 

Number (BSN) 

Identifies the sequence number of the transfer. 

All transfers are sequentially numbered fi’om a 
spedfic subscriber to permit receiving stations 
to recognize missed messages. 

b. Transport Message 

The actual message at the Transport layo" that 
is bdng transferred between OTCIXS n 
subscribers. The format of the Transport Layer 
Message is as defined in the TADIXS IDS, 
Volume I. 

c. Block Check Sequence (BCS) 

Provides an error detection code for the 
Transport Layw message as described in 
.i^pendkb. Calculated over all bytes of the 
Transoort Messaae field. 

2. Reservation Request Transmission 

Unit (RRTU) 

A TU transmitted in an RS to request service; 
that is, time on the OTCIXS n network to 
transmit a STU. Notifies the NCS that a net 
subsaiber requires net service. 

a. Component Identification (CID) 

Identifies the TU as an RRTU. 

b. Copy 

Identifies the number of times, including this 
transmission, that this RRTU has been 
transmitted in the current net cycle. 

c. Mode (BCS) 

Identifies the type of request being made. 

Posable service requests are: 


a. Nonscheduled transmission of Flash 
precedence STU 

b. Nonscheduled transmission of Immediate 
precedence STU 

c. Scheduled broadcast transmission of STU 
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Table 3-4. Subscriber to NCS Signal Definition List (cont.) 


SIGNAL 

d. Retry Count 

e. Subscriber Identification (SID) 

f. Transmit Count (XMIT CT) 

g. Transmit Minute 



DEFINITION 

Indicates the number of times a subscriber has 
attempted net entry prior to acknowledgment 
by the NCS in the NCB. 

Identifies the OTCKS n subscriber that is 
making the request. 

bidicates the number of times the subscriber 
desires to transmit its STU. 

When the MODE field indicates that a 
scheduled broadcast is required, this field 
identifies the minute, within the hour, at which 
that broadcast is to occur. 

Provides the transmisrion entity for the 
Transport layer entities (e.g., formatted 
computer-to-computer data and tdetype 
messages). 


Identifies the number of times, including this 
transmisrion, that this STU has been 
transmitted in the current net cycle. 

Identifies how many network messages are 
present in the STU and, for each such message, 
a pointer to the start of the message in the 
STU. Also contains a Pointer Check Sequence 
(PCS), calculated in accordance with Appendix 
B, to ensure the validity of the message pointer. 

When the RESV field indicates that this STU 
contains a piggybacked service request, this 
field identifies the type of request bang made. 
Possible service requests are; 


Identifies the TU as a STU 
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Table 3-4. Subscriber to NCS Signal Definition List (cont.) 


SIGNAL 

DEFINmON 

d. Mode (cont.) 

a. Nonscheduled transmission of Flash 
precedence STU required 

b. Nonscheduled transmission of Immediate 
precedence STU required 

c. Scheduled broadcast transmission of STU 
required 

d. Nonscheduled transmission of Immediate 
precedence STU predicted. 

e. More 

Indicates if additional service is required for 

STU transmisaon on the current broadcast 
schedule (i.e., the current scheduled broadcast 
cannot be completed in a angle STU). 

f. Netwoiic Message 

Contains a Transport Message and a BCS. 

Also identifies the BSN for the transaction. 

g. Precedence (PREC) 

Identifies the precedaice level of the STU as 
atiiCT Immediate or Flash. 

h. Reservation (RESV) 

Indicates whether this STU contains a 
piggybacked service request. 

i. Subscriber Identification (SID) 

Identifies the OTCIXS n subscriber that 
ori^ated the STU transmission 

j. Transmit Count (XMIT CT) 

When the RESV field indicates that a 
piggybacked RR is present, this field indicates 
the number of times the STU referenced by that 
request is to be transmitted. 

k. Transmit Minute 

When the RESV field indicates that a 
piggybacked service request for a scheduled 
broadcast is present, this field indicates the 
minute, within the hour, at which that broadcast 
is to occur. 
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Table 3-5. Subscriber to Subscriber Signal Definition List 


_ SIGNAL 

1. Network message 


_ DEFESirnON _ 

Provides the vehicle for transferring a 
Transport Message. Also provides for 
sequencing, to peraiit identification of missed 
messages, and error detection. 


a. Broadcast Sequence Number 
(BSN) 


b. Transport Message 


c. Block Check Sequence ^CS) 


2. Subscriber Transmisaon Unit (STU) 


Identifies the sequence number of the transfer. 
All transfers are sequentially numbered fi'om a 
spedfic subscriber to permit recdving stations 
to recognize missed messages. 

The actual message at the Transport layer that 
is bang transferred between OTCIXS n 
subsaibers. The fi)rmat of the Transport 
Layer Message is as defined in the TADIXS 
IDS, Volume I. 

Provides an error detection code for the 
Transport Layer message as described in 
Appaidix B. Calculated over all bytes of the 
Transport Message field. 

Provides the transmisaon entity for the 
Transport Layer entities (e.g., formatted 
computer-to-computer data and teletype 
messages). 


a. Component Idartification (CED) 


Identifies the TU as an STU. 


b. Copy 


Identifies the number of times, including this 
transmisMon; that this STU has been 
transmitted in the current net cycle. 


c. Message Pointer Block 


Identifies how many network messages are 
present in the STU and, for each such 
message, a pointer to the start of the message 
in the STU. Also contains a PCS, calculated in 
accordance with Appendix B, to ensure the 
validity of the message pointers. 
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Table 3-5. Subscriber to Subscriber Signal Definition List (cont.) 


SIGNAL . 

DEFBSimON 

d. Mode 

When the RSV field indicates that this STU 

contains a piggybacked savice request, this 

field identifies Ae type of request bang made. 

Possible service requests are: 

a. Nonscheduled transmission of Flash 
precedence STU required 

b. Nonscheduled transmission of Immediate 
precedence STU required 

c. Scheduled broadcast transmission of STU 
required 

d. Nonscheduled transmission ofhnmediate 
precedence STU predicted. 

e. More 

This field is interpreted by NCS. It is not 
interpreted by the recdving subscriber. 


Indicates if additional service is required for 

STU transmission on the current broadcast 
schedule (i.e., the current scheduled broadcast 
cannot be completed in a single STU). 


This field is interpreted by NCS. It is not 
interpreted by the recdving subscriber. 

£ Netwoik Message 

Contains a transport message and a BCS. 

Also identifies the BSN for the transaction. 

g. Precedence (PREC) 

Identifies the precedence level of the STU as 
dther Immediate or Flash. 

h. Reservation (RESV) 

Indicates whether this STU contains a 
piggybacked service request. 

i. Subscriber Identification (SID) 

This field is interpreted by NCS. It is not 
interpreted by the recdving subscriber. 


38 





Table 3-5. Subscriber to Subscriber Signal Definition List (cont.) 


SIGNAL 

DEFINmON 

j. Transmit Count (XMIT CT) 

Identifies the OTCDCS n subscriber that 
originated the STU transmission. 


When the RES V field indicates that a 
piggybacked RR is present, this field indicates 
the number of times the STU referenced by that 
request is to be transmitted. 

k. Transmit Minute 

This field is interpreted by NCS. It is not 
interpreted by the recdving subscriber. 


When the RESV field indicates that a 
piggybacked service request for a scheduled 
broadcast is present, this field indicates the 
minute, within the hour, at which that broadcast 
is to occur. 


This field is interpreted by NCS. It is not 
interpreted bv the recdvine subscriber. 
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IV. NARRATIVE SIGNAL FLOW TABLE 


A. GENERAL. 

The section provides a narrative tabulation by logical signal groupings of signal flow 
between OTCIXS n subsaibers. Also included are the Physical Layer signals used by the 
OTCIXS n Link Controllers (LC) to control and monitor the: 

1. KG-84A cryptographic device 

2. TD-1271BAJDAMAmultipl©i:er 

3. AN/WSC-3/5 transceiver. 

This tabulation provides a description of the tignal, flow direction, initiation, response 
and amplifying remaiks. 

B. SIGNAL FLOW TABLES. 

1. Physical Layer. 

Table 4-1 presents the agnal flow table for the Physical Layer. The narrative agnal 
flow for the Physical Layo* is presented in the following logical groupings: 

a. Non-DAMA Mode Data Transmission 

b. Non-DAMA Mode Data Reception 

c. DAMA Mode Data Transmisaon 

d. DAMA Mode Data Reception 

e. Crypto Error Handling. 

2. Data Link and Networi^ Layer. 

As described in section 4, the Data Link Laypr is cfos^y tied to the Network Layer, 
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therefore these layers are presented in a ^gle signal flow table. Table 4-2 presents the signal 
flow table for the Data Link and Network Layers. A single narrative signal flow. Message 
Transfer, for these layers is presented. 

Table 4-1. Physical Layer Signal Flow 


SIGNAL 


HESiiSiSSHi 



1. Non-DAMA 





Mode Data 
Transmission 





a. Keyline 

OTCKSHLC 

Kq^line is asserted 

TheAN/WSC-3/5 

Keyline is 


toANAVSC- 

when transmission 

transceiver 

removed 


3/5 transceiver 

of a TU on the 

generates a modem 

immediately 



satellite link is 

preamble which is 

following the 



required. 

60 ms in duration 

completion of TU 




after a 40 ms power 
up delay and pre- 

transmission. 




pares to receive 

For repeated 




Transmit Data for 

copies of a TU 




transmission. 

transmission (i.e., 
multiple copies of 
a TU in a single 
net cycle). 

Key line will be 
reasserted for 
each copy 
transmitted. 

b. Crypto PREP 

OTCIXSnLC 

Crypto PREP will 

TheKG-84A 

Crypto PREP is 


to crypto 

be asserted 

executes an alarm 

received by the 



immediately 

check sequence and 

KG-84Aas 



following keyline 

transmits a crypto 

SYNC-CMD-TX. 



assertion. 

pre-amble which 
will be received by 
other KG-84A 

The duration of 




cryptos on the 

the 




OTCKS n 

^chronization 




network. 

pattern generated 
bytheKG-84A 
will be 

approximately 

364 bit times 
when the 
baseband data 
rate is 2400 bps 
and 381 bit times 
when it is 4800 
bps. 





Receivine crvntos 
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FROMH-O 

INITIATION 



1. Non-DAMA 
Mode Data 
Transmission 

a. K^line 

OTcrxsnLC 
toAl^SC- 
3/5 transceiver 

Keyline is asserted 
when transmission 
of a TU on the 
satellite link is 
required. 

TheAN/WSC-3/5 
transceiver 
generates a modem 
preamble which is 

60 ms in duration 
after a 40 ms power 
delay and pre¬ 
pares to receive 
Transmit Data for 
transmission. 

K^line is 
removed 
immediately 
following the 
completion of TU 
transmission. 

For repeated 
copies of a TU 
transmission (i.e., 
multiple copies of 
a TU in a single 
nettycle). 

Key line will be 
reasserted for 
each copy 
transmitted. 





of the same type 
as the 

transmitting 
crypto will 
acquire i^chron- 
ization with the 
transmitting 
crypto. 

Assertion of 

Crypto PREP will 
pre^e each TU 
transmission. 
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Table 4-1. Physical Layer Signal Flow (cont.) 


SIGNAL 

FROMTTO 

INITIATION 

RESPONSE 

RHVIARKS 

Non-DAMA 
Mode Data 
Transmission 
(cont) 

c. Transmit Data 
Red 

OTCDCSHLC 
to crypto 

After a crypto¬ 
type dependent 
delay following 
assertion of 

Crypto PREP (to 
allow for 
transmission of 
the crypto 
preamble). For 
the KG-84A this 
delay is dqiendent 
on the baseband 
data rate 
employed For 

2400the delay 
must be at least 

364 bit times. For 
4800 bps it must 
be at least 381 bit 
times. 

Crypto performs 
encryption of the 
received serial data 
and sends the 
resulting serial data 
stream to the black 
side of the OTCDCS 
n LC as Transmit 

Data Black 

Transmit Data Red 
is received by the 
KG-84Afix>mthe 
red side of the 
OTCKS HLC as 
TX-DPT. For the 
KG-84A, the first 
two bytes of 
Transmit Data Red 
must be the 

BISYNC code to 
permit data 
synchronization by 
the receiving 
processor. 

d Transmit Data 
Black 

Crypto to 
OTCIXSnLC 

Following receipt 
of serial data 
(Transmit Data 
Red) by the crypto 
and encryption of 
that data. 

Transmit Data Black 
is received from the 
crypto by the black 
side of the OTCDCS 
HLC. 

Received serial data 
is immediatety 
forwarded as 

Transmit Data to the 
AN/WSC-3/5 
transceiver for 
transmission. 

Transmit Data 

Black is sent by 
theKG-84Aas 
ETCT. 

e. Transmit Data 

OTCKSHLC 
to AN/WSC- 
3/5 transceiver 

FoUowing receipt 
of serial data 
(Transmit Data 
Black) from the 
Crypto. 

Received serial data 
is transmitted on the 
OTCKS n rf 
charmel. 

Transmit data is 
received by the 
transceiver fiom 
the black side of 
the OTCIXS n 

LC. 
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Table 4-1. Physical Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

2. Non-DAMA 
Mode Data 
Reception 

a. Channel Busy 

AN/WSC-3/5 
transceiver to 
OTCIXSnLC 

Presence of a 
receive signal at 
the AN/WSC-3/5 
transceiver. 

Prepare to receive 
the crypto preamble 
and transmitted TU. 


b. Receive Data 

AN/WSC-3/5 
transceiver to 
OTCDCSHLC 

Presence of a 
receive signal. 

Received serial data 
is forwarded to the 
crypto as Receive 

Data Black. If 
crypto preamble is 
detected prepare to 
receive transmitted 

TU. 

Receive Data is 
received from the 
AN/WSC-3/5 
transceiver by the 
black side of the 
OTCDCSHLC. 

c. Receive Data 
Black 

OTCDCSHLC 
to crypto 

Following receipt 
of Receive Data 
from the 
AN/WSC-3/5 
transceiver. 

Crypto performs 
dec^tion of the 
received serial data 
and sends the 
resulting serial data 
stream to the red side 
of the OTCKS H LC 
as Receive Data Red 

Receive Data 

Black is received 
bytheKG-84A 
from the black side 
oftheOTCDCSH 
LCasERCT. 

d Receive Data 
Red 

Crypto to 
OTCDCSHLC 

Following receipt 
of serial data 
(Receive Data 
Black) by the 
crypto and 
decryption of that 
data. 

Receive Data Red is 
received from the 
crypto by the red side 
oftheOTCIXSELC 
and forwarded to the 
Data Link Layer for 
processing. 

Receive Data Red 
is sent by the KG- 
84AasRX-DPT. 

FortheKG-84A, 
the detection of a 
BISYNC code wiU 
signal the 
commencement of 
TU reception. The 
BISYNC code 
indicates that 
modem, crypto, 
and data 
^chronization 
has been achieved 
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Table 4-1. Physical Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

3.DAMA 

Mode Data 
Transmission 

a. Slot Time 

Mark (STM) 

TD-1271 BAJ 
to OTCEXS n 
LC 

Generated by the 
TD-1271B every 
1.38667 seconds 
to provide 
i^chronization 
with the DAMA 
frame. 


The transmission of 
the crypto preamble, 
which initiates TU 
transmission, is 
^chronized with 
receipt of STM. 

Failure to receive 

STM in a 2-second 
interval constitutes a 
link&ilure. 

b. External 
Transmit 
Request 

OTCDCSHLC 
to TD-1271 

B/U 

External Transmit 
Request is 
asserted when 
transmission of a 
TU on the satellite 
link is required. 

The TD-1271 B/U 
prepares to receive 
Transmit Data for 
transmission. 

External Transmit 
Request must be 
asserted only once 
for r^reated copies of 
a TU transmission 
(i.e., multiple copies 
of a TU in a single 
net cvcle). 

c. Crypto PREP 

OTCKSHLC 

toKG-84A 

crypto 

Crypto PREP will 
be asserted 
immediate^ 
following 

External Transmit 
Request assertioa 

TheKG-84A 
executes an alarm 
check sequence 
and transmits a 
crypto preamble 
which will be 
received by other 
KG-84A cryptos 
ontheOTCKSn 
network. 

■ 

Crypto PREP is 
received by the KG- 
84AasSYNC-CMD- 
TX. 

EachKG-84A 
receiving the crypto 
preamble will 
acquire ^chro- 
nization with the 
transmitting KG- 
84A. 

The duration of the 
synchronization 
pattern generated by 
theKG-84Awillbe 
at least 347 bit times 
when the basd>and 
data rate is 1200 bps 
and 364 bit times 
when it is 2400 bps. 
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Table 4-1. Physical Layer Signal Flow (cont.) 



FROM/TO 

INITIATION 

RESPONSE 

DAMA 

Mode Data 

Transmission 

(cont) 

c. Crypto PREP 
(cont) 




d. Transmit Data 

OTCIXSnLC 

Afierabasd)and 

TheKG-84A 

Red 

toKG-84A 

data rate 

performs 


crypto 

dependent delay 
following 
assertion of 

Crypto PREP (to 
allow for 
transmission of 
the crypto 
preamble). For 
1200 bps the delay 
must be at least 

347 bit times. For 
2400it must 
be at least 364 bit 
times. 

encryption of the 
received serial data 
and sends the 
resulting serial 
data stream to the 
black side of the 
OTCKS HLC as 
Transmit Data 
Black. 

e. Transmit Data 

KG-84A 

Following receipt 

Transmit Data 

Black 

crypto to 

of serial ^ta 

Black is received 


OTCKS HLC 

(Transmit Data 
Red) by the KG- 
S4Aand 

encryption of that 
data. 

from the crypto by 
the black side of 
the OTCKS n 

LC. 

f. Transmit Data 

OTCIXSnLC 

Following receipt 

Received serial 


toTD-1271 

of encrypted serial 

data is 


B/U 

data (Transmit 

Data Black) from 
the crypto. 

immediately 
forwarded as 
Transmit Data to 
theTD-1271B/U. 

Received serial 
data is transmitted 
in the DAMA 
timeslot. 


REMARKS 


Assertion of Crypto 
PREP will precede 
eachTU 

transmission on the 
satellite link. 

Transmit Data Red is 
received by the KG- 
84A fiom the red 
side of the OTCKS 
nLCasTX-DPT. 

The first two bytes of 
Tr ansmit Data Red 
must be the BISYNC 
code to permit data 
synchronization by 
the receiving 
processor. 


Transmit Data Black 
is sent by the KG- 
84AasETCT. 


Transmit data is 
received by the TD- 
1271 BfU from the 
black side of the 
OTCIXSnLC. 
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Table 4-1. Physical Layer Signal Flow (cent.) 


SIGNAL 


rNTTIATION 

RESPONSE 

RHVIARKS 

4.DAMA 

Mode Data 
Reception 

a. Signal 

Acquired 

(SIGACQ) 

TD-1271B/U 
to OTCKS n 
LC 

Presence of a 
receive signal at 
theTD-1271BAJ 
multiplexer. 

Prepare to receive 
the crypto 
preamble and 
transmitted TU. 


b. Receive Data 

TD-1271 B/U 
toOTCDCSn 
LC 

Presence of a 
receive signal. 

Received serial 
data is forwarded 
to the KG-84A as 
Receive Data 

Black. If crypto 
preamble is 
detected, prepare 
to receive 
transmitted TU. 

Receive Data is 
received from the 
TD-1271 B/U by the 
black side of the 
OTCDCSHLC. 

c. Receive Data 
Black 

OTCDCSHLC 

toKG-84A 

crypto 

Following receipt 
of Receive Data 
from the TD- 
1271B/U. 

TheKG-84A 
performs 
decryption of the 
received serial data 
and sends the 
resulting serial 
data stream to the 
red side of the 
OTCDCSHLC as 
Receive Data Red. 

Receive Data Black 
is received by the 
KG-84A from the 
black side of the 
OTCDCSHLC as 
ERCT. 

d. Receive Data 
Red 

Crypto to 
OTCDCSHLC 

Following receipt 
of serial data 
(Receive Data 
Black) the 
crypto and 
decryption of that 
data. 

Receive Data Red 
is received fix>m 
the crypto by the 
red si^ of the 
OTCDCSHLC 
and forwarded to 
the Data Link 

Layer for 
processing. 

Receive Data Red is 
sent 1^^ the KG-84A 
asRX-DPT. 

The detection of a 
BISYNC code wiU 
signal the 
commencement of 
TUrecqrtion. The 
BISYNC code 
indicates that 
modem, crypto, and 
data synchronization 
has been achieved. 
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Table 4-1. Physical Layer Signal Flow (cont.) 



FROM/TO 


RESPONSE 

REMARKS 

5. Crypto Error 
Handling 

a. Ciypto Alann 
Indicate 

Ciypto to 
OTCIXSnLC 

By the crypto to 
indicate that it is 
in an alarm state. 

TheOTCKSn 

LC shall attempt 
to clear the alarm 
state by signaling 
Ciypto Alarm 

Reset. 

If the ciypto still 
indicates an alarm 
condition after 
three alarm reset 
attempts, the 
OTCKSHLC 
shall consider the 
interface to be 
inoperable. 

Crypto Alarm 
In^cateissentby 
the KG-84 A as RED- 
AI. 

b. Ciypto Alann 
Reset 

OTCKSHLC 
to crypto 

By OTCKSHLC 
to clear the alarm 
state of its crypto 
indicated by 
reception of 

Ciypto Alarm 
Indicate. 

The ciypto •will 
attempt to clear 
the Crypto Alarm 
Indicate signal and 
take itself out of 
the alarm state. 

Ciypto Alarm Reset 
is received by the 
KG-84AasRP- 
STBYR. 

The OTCKSHLC 
will continue to 
attenpt to clear the 
alarm state until the 
Crypto Alarm 

In^cate signal is 
removed. 




49 













Table 4-2. Data Link and Network Layer Signal Flow 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

1. Messs^e 





Transfer 





a. Net Control 

Net Control 

Sent at the 

The packet CRC of 

Processing of the 

Block (NCT) 

Station 

following times to 

the Data Link Layer 

NCB's triply 

Transmission 

(NCS)to 

mark the 

packet containing the 

redundant fields or 

Unit(TU) 

Subscriber 

begiiming of an 

NCB shall be 

of the HOURS, 



OTCKS n net 

validated calcu¬ 

MINUTES, and 



cycle: 

lating the packet 

SECONDS fields 




CRC and comparing 

(which are validated 



a. Upon 

it with the CRC 

against the TIME 



completion of NCS 

value present in that 

CHECKSUM field) 



initialization 

packet. S’validation 

shall be performed 



processing. 

is not achieved, the 

even when the packet 




packet shall be 

CRC cannot be 



b. Upon 

marked as bad and 

validated. 



completion of an 

replaced with a 




idle cycle 

packet received in a 
repeat transmission 




c. Upon 

of the NCB if such a 




completion of a 

transmission is 




busy cycle 

received. Alter all 
repeats of the NCB 
have been received 
or an error-free NCB 
is received, 
processing of the 

NCB shall continue 
as follows: 


a. Net Control 

Net Control 


1. Validate the NCB 

Validation of the 

Block (NCB) 

Station 


triply redundant 

triply redundant 

Transmission 

(NCS) to 


fields: 

fields requires 

Unit(TU) 

Subscribers 



draining at least a 

(cont.) 



a. S validation of the 

two out of three 




CID field caimot be 

match. 




achieved, the NCB 
shall be discarded. 

The received TU 




In that case, wait for 

cannot be identified 




transmission of 

as an NCB TU if the 




another NCB TU. 

CID value is invalid. 




b. S validation of the 

Processing of the 




NCS SID field is 

NCB shall continue 




achieved, perform 

even when the NCS 




the following 

SID field cannot be 




operations: 

validated. 









Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION __ 

RESPONSE 

REMARKS 

Mess^e 

Transfer (cont) 

a. Net Control 
Block (NCB) 
Transmission 
Unit (TU) 

(cont) 

Net Control 

Station 

(NCS)to 

Subscribers 

(cont) 


If the receiving sub¬ 
scriber is selected as 
NCS(i.e.,theNCS 
receives an NCB TU 
from another sub¬ 
scriber), generate a Dual 
NCS alert. 

When an NCS is 
active, all other 
subscribers shall be 
prevented, via 
software, fix>m 
assuming NCS. 

a. Net Control 
Block (NCB) 
Transmission 
UnitCrU) 

(cont.) 

Net Control 

Station 

(NCS)to 

Subscribers 

(cont) 


If the value of the NCS 
SID is the same as that 
assigned to the receiving 
subscriber, generate a 

Dual SID alert 

If the value of the NCS 
SID is not the same as 
the last correct 
validation received on 
an NCB TU, generate a 
New NCS alert 

Processing of NCB 

TU shall continue 
even when the 
WINDOW SIZE and 
HITS fields cannot 
be validated. 

Processing of the 

NCB shall continue 
even when the SB 
STATUS field 
cannot be validated. 




If the receiving 
subscriber is not NCS, 
record the net as 
operational with the 
subscriber identified by 
the NCS SID field as the 
NCS. 





c. fr validation of the 
WINDOW SIZE and 
HITS fields is achieved, 
iqxlate the current 
values of these items 
with those in these 
fields. 





d. If validation of the SB 
STATUS field is 
achieved and the 
contents of that field 
indicate that a scheduled 
broadcast requested by 
the receiving subscriber 
has been preempted, 
consider the broadcast 
completed. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer (cont) 





a. Net Control 
Block (NCB) 
Transmission 
UnitCrU) 

(cont) 

Net Control 
Station (NCS) 
to Subscribers 
(cont) 


e. If validation of the 
RATS TYPE, and 

FLASH and 
IMMH)IATE SLOTS 
fields is achieved and 
the receiving subscriber 
has an STU to transmit 
randomly select an RS 
and send a RRTU in the 
RATS to request link 
time to transmit that 

STU. 


a. Net Control 
Block (NCB) 
Transmission 
UnitCrU) 

(cont) 

Net Control 
Station (NCS) 
to Subscribers 
(cont) 


f. If validation of the 
GSID, RATS TYPE, 
and FLASH and 
IMMEDIATE SLOTS 
fields is achieved and 
the contents of the GSID 
field matches the receiv¬ 
ing subscriber's SID, the 
receiving subscriber has 
been granted authority 
to transmit. 

If an STU is available 
for transmission, the 
receiving subscriber 
shall immediately com¬ 
mence transmission of 
the STU. If additional 
link time is required, the 
subscriber shall notify 
NCS of the requirement 
by piggybacking a ser¬ 
vice request in the 
transmitted STU. 

If the STU 
transmission is by 
scheduled broadcast, 
NCS shall authorize 
transmission by the 
subscriber no more 
than 45 seconds after 
the scheduled time. 

Ifit cannot, NCS 
shall notify the 
subscriber that the 
scheduled broadcast 
has been preempted. 
NCS control of STU 
transmission by 
scheduled broadcast 
shall be as described 
in section 6. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer (cont) 

a. Net Control 
Block (NCB) 
Transmission 
UnitCrU) 

(cont) 

Net Control 
Station (NCS) 
to Subscribers 
(cont) 


If the receiving 
subscriber's SID does 
not appear in one of 
those fields, a No NCS 
Acknowledgement alert 
shall be generated. 

b. The receiving 
subscriber shall retain 
the LAQ information for 
use in the event that the 
subscriber must assume 
NCS responsibilities. 

The LAQ 

information shall be 
ignored if validation 
of the Data Link 

L^er packet 
containing the NCB 
could not be 
achieved. 

b. Reservation 
Request 
Transmission 
Unit(RRTU) 

Subscriber to 
NCS 


The receiving subscriber 
shall also validate that 
aU its unfulfilled 
requests for link time 
are present Any 
request for which an 

LAQ entry is not present 
shall be resubmitted. 

If a request was 
made in the 
preceding net cycle, 
via an RRTU, and 
the subscriber's SID 
does not appear in 
the LAQ, a collision 
of the request with 
that of another 
subscriber has 
occurred and the 
subscriber shall 
perform the 

Contention Resolu¬ 
tion Algorithm 
(CRA) as discussed 
in section 6. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 




RESPONSE 


Message 

Transfer (cont) 
b. Reservation 
Request 
Transmission 
UnitCRRTU) 
(cont) 

Subscriber to 
NCS (cont.) 

Following 
validation of 
the RATS 
TYPE, 

FLASH, and 
IMMEDIATE 
SLOTS fields 
of a received 
NCB, the 

RRTU is sent 
by a 

stibsctiber 
during one of 
the RSs in the 
RATS to 
request link 
time to 
transmit a 

STU. 

The packet CRC of the 
Data Link Layer packet 
containing the RRTU 
shall be validated by 
calculating the packet 
CRC and comparing it 
with the CRC value 
present in that packet. 

If validation is not 
achieved, the packet 
shall be marked as bad 
and replaced with a 
packet received in a 
repeat transmission of 
the RRTU if such a 
transmission is received 
After aU repeats of the 
RRTU have been 
received or an error-fiee 
RRTU is received, 
prcKessing of the RRTU 
shall continue as 
follows: 

Processing of the 
RRTlPs triply 
redundant fields 
shall be performed 
even when the packet 
CRC cannot be 
validated 

b. Reservation 
Request 
Transmission 
Unit^RTU) 
(cont.) 

Subscriber to 
NCS 


1. any of the RRlXTs 
triply redundant fields 
cannot be validated, the 
request shall be ignored 

2. If validation is 
achieved and: 

a. Contents of the SID 
field is the receiving 
station's SID, the 
request shall be ignored 
and a Dual SID alert 
shall be generated 

Validation of the 
triply redundant 
fields requires 
obtaining at least a 
two out of three 
match. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INrriATI 

ON 

RESPONSE 

REMARKS 

Message Transfer 
(cont) 





b. Reservation 
Request 
Transmission 
Unit(RRTU) 
(cont) 

Subscriber to 
NCS (cont.) 


b. Request is a non- 
scheduled request, the 
request shall be placed 
in the LAQ according to 
its precedence. 

Presence of the 
requester’s SID in 
the LAQ provided in 
the next NCB TU 
sent by NCS shall 
serve as acknow¬ 
ledgement of receipt 
of the request. NCS 
processing of 
subscriber requests 
and the method 
which those requests 
are entered into the 
LAQ are described in 
section 6. 



I 

c. Request is a sche¬ 
duled request the 
request shall be placed 
in the LAQ according to 
its precedence but shall 
be unavailable for 
selection until the time 
indicated in the request 
occurs. If the subscriber 
• is already on the LAQ 
with a scheduled 
broadcast request the 
RRTU Transmit Minute 
shall be used to update 
the subscriber's 
scheduled request entry. 

If the requester's SID 
does not appear in 
the LAQ received in 
the following net 
c^cle, a collision of 
the request with that 
of another subscriber 
has occurred and the 
subscriber shall 
perform the 

Contention Resolu¬ 
tion Algorithm 
(CRA) as discussed 
in section 6. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 



FROM/TO 

WBBWBSMil 

RESPONSE 

REMARKS 

Message 

Transfer (cont) 





c. Subscriber 

NCS/Sub- 

Sent by a 

For each Data Link 

Processing of the 

Tiaosmission 

scriberto 

subscriber in 

Layer packet containing 

STU shall be 

Uiiit(STU) 

Subscriber 

response to the 

the received STU, the 

performed even 


receipt of an 

packet CRC iriiall be 

when all packet 



NCBTU 

validated by calculating 

CRCs cannot be 



designating the 

the packet OR.C and 

validated. 



subscriber as the 

comparing it with the 




granted 

CRC value present in 




subscriber (i.e.. 

that packet tfvalida- 




the GSID field 

tion is not achieved on a 




intheNCB 

packet, that packet shall 




contains the 

be marked as bad and 




subscriber's 

rq>laced with a corres- 




SID). 

ponding packet received 




SenlhyNCS 

in a repeat transmission 




when it 

of the STU if such a 




detennines that 

transmission is received 




it is the granted 

After all repeats of the 




subscriber (i.e.. 

STU have been received 




it has placed its 

or an error-ftee STU is 




SID in the GSID 

received, processing of 




field of the NCB 

the STU shall continue 




for this net 

as follows; 




cycle). 

l.Validate the STU 

Validation of the 




triply redundant fields. 

triply redundant 
fields requires 
obtaining a two 
out of three match. 




a. If validation of the 

The received TU 




CID field cannot be 

caimotbe 




achieved, the STU shall 

identified as an 




be discarded. In that 

STU if the CID 




case, wait for the 
transmission of another 
TU. 

value is invalid. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 


REMARKS 

Message Transfer 
(cont) 





c. Subscriber 
Transmission 

Unit (STU) 
(cont.) 

NCS/Sub- 

scriberto 

Subscriber 


b. If validation of the 

SID field is achieved 
and the SID is equal to 
the receiving sub¬ 
scriber's SID generate a 
Dual SID alert. 

Processing of the 
STU shall be 
performed even 
when file contents 
of the SID field 
cannot be 
validated. 

c. Subscriber 
Transmission 

Unit (STU) 
(cont) 

Subscriber 

toNCS 


2. Validate the contents 
of the Message Pointer 
Block by calculating a 
CRC on its fields 
(exclusive of the PCS 
field) and comparing it 
to the contents of the 

PCS field. Ifa match is 
not obtained, the entire 
STU shall be discarded. 

Individual 
messages in the 

STU cannot be 
property delimited 
if the contents of 
the Message 

Pointer Block 
cannot be 
validated. 




3. If the contents of the 
Message Pointer Block 
was validated, use the 
Message Pointers to 
extract each of the 
network messages fix>m 
the STU. If the message 
is addressed to the 
receiving subscriber, 
process the message 
accordingly. If STU 
recqMion was via an 
OTCKSHLC, 
formatted computer-to- 
computer messages are 
transferred to the TDP 
and TTY messages are 
transferred to the 
teletype. If STU 
recqition was via an 
OTCEXSnLC (within a 
TGF), all messages are 
transferred to the TCff. 

Refer to TADIXS 
EDS Volume I for 
the format of the 
transport messages 
contained in the 
network messages. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 



FROM/TO 




Message 

Transfer (cont.) 

c. Subscriber 
Transmission 
Unit (STU) 
(cont.) 

Subscriber to 
NCS (cont.) 

Sent by a 
subscriber in 
response to the 
receipt of an 
NCBTU 
designating the 
subscriber as 
the granted 
subscriber (i.e., 
the GSID field 
in the NCB 
contains the 
subscriber's 

SID). The 
transmitting 
subscriber shall 
transmit the 

STU the 
number of 
times specified 
in the received 
NCBTU. 

Messages containing 
embedded errors (i.e., 

CRC at end of message 
does not match 
computed QIC over 
message) shall be so 
noted when transferred 
to the TDP or TGP. 

For each Data Link 

Layer packet containing 
the received STU, the 
packet CRC shall be 
validated by calculating 
the packet CRC and 
comparing it with the 
CR(3 value present in 
that packet. If valida¬ 
tion is not achieved on a 
packet, that packet shall 
be marked as bad and 
replaced with a corres¬ 
ponding packet received 
in a rq)eat transmission 
of the STU if such a 
transmission is received. 
After all repeats of the 
STU have been received 
or an error-fiee STU is 
received, processing of 
the STU shall continue 
as follows; 

Processing of the 

STU shall be 
performed even 
when all packet 

CRCs cannot be 
validated. 

Subscriber 

Transmission 

Unit (STU) 

(cont.) 

Subscriber to 
NCS (cont.) 


l.ValidatetheSTU 
triply redundant fields. 

Validation of the 
triply redundant 
fiel(k requires 
obtaining a two 
out of three match. 

Subscriber 
Transmission 
Unit (STU) 

(cont.) 

Subscriber to 
NCS (cont.) 


a. If validation of the 

CID field caimot be 
achieved, the STU shall 
be discarded. In that 
case, wait for the 
transmission of another 
TU. 

The received TU 
cannot be 
identified as an 

STU if the CID 
value is invalid. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROMATO 

INITIATION 

RESPONSE 

REMARKS 

Message 
Transfer (cont) 

Subscriber 

Transmission 

Unit(STU) 

(cont) 

Subscriber to 
NCS (cont) 


b. If validation of the 

SID field is achieved 
and the SID is equal to 
the receiving sub¬ 
scriber's SID, generate a 
Dual SID alert. 

Processing of a 
piggy-backed RR 
shall not be 
performed if the 
contents of the SID 
field cannot be 
validated. Other 
portions of the 

STU shall be 
processed even 
when the contents 
of the SID field 
cannot be 
validated. 

Subscriber 

Transmission 

Unit(STU) 

(cont.) 

Subscriber to 
NCS (cont) 


c. If validation of the 
RESV, MODE, XMIT 
CT, TRANSMIT 
MINUTE, and MORE 
fields cannot be 
achieved, NCS shall not 
perform piggy-back net 
service request 
processing on the STU. 

The NCS cannot 
identify the 
requesting subs- 
criber's 
transmission 
requirements if 
these fields cannot 
be validated 

Subscriber 

Transmission 

Unit(STU) 

(cont) 

Stibscriber to 
NCS (cont.) 

j 

d. If validation of the 
RESV, MODE, XMTT 
CT, TRANSMIT 
MINUTE, and MORE 
fields is achieved and 
the contents of the 

RESV field indicates 
that the subscriber has 
piggybacked a request 
for additional net 
service in the STU: 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FROM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer 

(cont) 





Subscriber 
Transmission 
Unit (STU) 

(cont) 

Subscriber to 
NCS (cont) 


If the request was for 
nonscheduled services, 
the request shall be 
placed in the LAQ 
according to its 
precedence. Presence of 
the requester's SID in 
the LAQ provided in the 
next NCB TU sent 

NCS shall serve as 
acknowledgement of 
receipt of the request. 

NCS processing of 
subsCTiber requests 
andthe meth^by 
which those 
requests ate 
entered into the 

LAQ are as 
described in 
section 6. 

Subscriber 
Transmission 
Unit (STU) 
(cont.) 

Subscriber to 
NCS (cont) 


If the request is for 
scheduled services, the 
request shall be placed 
in the LAQ according to 
its precedence but shall 
be unavailable for 
selection until the time 
indicated in the request 
occurs. Presence of the 
requester’s SID in the 
LAQ provided in the 
next NCB TU sent 

NCS shall serve as 
acknowledgement of 
receipt of the request. 





e. If validation of the 
MORE field is achieved 
and its contents 
indicates that the 
requesting subscriber 
has an additional service 
requirement for STU 
transmission on the 
current broadcast 
schedule, the NCS shall 
indicate the requesting 
subscriber’s SID as the 
Granted SID (GSID) in 
the next NCB it sends. 

If a Flash 
precedence entiy is 
present in the 

LAQ or if more 
than five minutes 
have elapsed since 
the onset of the 
first net cycle 
allocated to this 
scheduled 
broadcast, the 

NCS shall reject 
the request and 
indicate the 

rejection by 

including a 
scheduled 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 


SIGNAL 

FRCM/TO 

INITIATION 

RESPONSE 

REMARKS 

Message 

Transfer (cont) 





Subscriber 

Transmission 

Unit (STU) 

(cont.) 

Subscriber to 
NCS (cont) 


e. (cont) 

broadcasting status 
of preempted in 
the next NCB it 
sends. Upon 
detecting this 
status, subscribers 
monitoring the 
scheduled 
broadcast shall 
consider the 
scheduled 
broadcast to be 
concluded. 

Subscriber 

Transmission 

Unit (STU) 

(cont) 

Subscriber to 
NCS (cont) 


2. Validate the contents of 
the Message Pointer Block 
by calculating a CRC on 
its fields (exclusive of the 
PCS field) and comparing 
it to the contents of the 

PCS field. Ifa match is 
not obtained, the entire 

STU shall be discarded. 

Individual 
messages in the 
STUcaimotbe 
properly delimited 
ifthe contents of 
the Message 

Pointer Block 

caimotbe 

validated. 




3. If the contents of the 
Message Pointer Block 
was validated, use the 
Message Pointers to 
extract each of the 
network messages from 
the STU. If the message is 
addressed to the NCS, 
process the message 
accordingly. If STU 
reception was via an 
OTCKS n LC, formatted 
computer-to-computer 
messages are transferred 
to the TOP and TTY 
messages are transferred 
to the tele^^pe. 

Refer to TADKS 
IDS Volume I for 
the format of the 
transport messages 
contained in the 
netwoik messages. 
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Table 4-2. Data Link and Network Layer Signal Flow (cont.) 



FROM/TO 

INITIATION RESPONSE 

REMARKS 

Message 

Transfer (cont) 

Subscriber 

Transmission 

Unit(STU) 

(cont.) 

Subscriber to 
NCS (cont) 


3. (cont.) If STU 
reception was via an 
OTCKS n LC (within a 
TGF), all messages are 
transferred to the TGP. 

Messages containing 
embedded errors (i.e., 

CRC at end of message 
does not match computed 
CRC over message shall 
be so noted when 
transferred to the TOP or 
TGP. 
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V. COMMUMCATION CONTROLS AND CONVENTIONS 


A. GENERAL. 

This section provides a description of the requironents assodated with transfer of data 
among OTCIXS n net manbers. Included are descriptions and procedures r^arding: 

1. Communication controls to provide data flow, data synchronization, error detection 
and correction. 

2. Communication conventions to support OTCIXS H Link Controller initialization 
and information transfer. 

OTCIXS n shall operate either via a permanently assigned UHF-DAMA Time 
Division Multiple Access (TDMA) baseband slot (i.e., DAMA Mode) or over an allocated 
UHF SATCOM chaimel (i.e., Non-DAMA Mode). The two modes are mutually 
exclusive" a given net may operate in one or the other of the two modes but not in both at 
the same time. 

To support the transfer of data on the net, OTCIXS n shall implemcait a computer-to 
computer protocol which enqrloys a layering concept consistent with the Internal Standards 
Organization (ISO) reference model. Each layer builds upon the services provided by the 
lower layer and converses with its correspondent layer in the other processor. Figure 5-1 
illustrates this layering concept. 

B. COMMUNICATION CONTROLS. 

The Physical, Data Link, and Network protocol layers shall provide the communication 
controls governing transfer of subscriber data among OTCIXS n net members. The support 
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provided by each of these protocol lay^ is described in the following paragraphs. 



Figure 5-1. OTCDCS n Protocol Layers 


1. Physical Layer. 

The Physical Layer shall provide the phyacal means for supporting all higher protocol 
layers and conasts of user baseband and radio frequenqr (rQ disdplines. These disciplines and 
the timing and sequendng of the physical layer agnals are described in the following 
subparagraphs. 

a. Uso" Baseband. 

In DAMA mode of operation, data shall be transferred serial synchronously in 
accordance with MIL-STD-188C at a baseband data rate of 1200 or 2400 bps. In 
Non-DAMA mode of operation, data shall be transmitted serial synchronously in accordance 
with MIL-STD-188C at a baseband data rate of2400 or 4800 bps. The baseband data rate to 
be used in a particular OTCIXS H network shall be used by all members of that network. The 
data shall be transmitted in 8-bit l^es least significant bit first. Parity bits shall not be used. 
For the KG-84A cryptographic device, all user data transmisaons shall be preceded by 
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transmisMon of one BISYNC code (two consecutive ASCII SYN (16 hexadedmal) codes). 
b. Radio Frequency. 

A given OTCKS n rf network shall operate either over a permanently 
assigned UHF-DAMA user slot (DAMA mode) or ova- an asagned UHF Satellite 
communication channel (Non-DAMA mode). 

(1). DAMA Mode. All members ofa^en DAMA Mode OTCIXSn 


if netwoik shall; 

(a) . Transmit on the same assigned uplink frequency and receive 
downlink broadcasts on the same translated downlink frequency. 

(b) . Transmit baseband data to, and receive baseband data from, a 
TD-1271B/U DAMA device operated with the Transmit Override option. The half-duplex 
mode of operation shall be used. 

(c) . Use a KG-84A cryptographic device. 

The TD-1271B/U operates as a modan and as a time diviaon multi¬ 
plexer. It accumulates user baseband data over 1.38667 second frame-time intervals and bursts 
the accumulated data over the satellite link. These uplink data bursts are recdved from the 
downlink, buffered, and presented at the original baseband rate. User basdjand data is buffered 
by the TD-1271B/U until it is time to present that data to the UHF uplink transmit subs 3 rstem. 
The size of a buffer (in bits) depends upon the user baseband rate and is the product of that rate 
and the frame time (rounded down to the nearest int^er); a 2400 bps basdrand rate employs a 
3328-bit buffer. Unused portions of the buffer are padded with binary ones on the left to fill 
space between assertion of STM and reception of the first bit of the user's baseband 
transmisaon. In principle, the TD-1271B/U insulates its user(s) from the if portion of the 
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satellite cotrnnunication process and, in &ct, physically separates those users from TJHF radio 
transcdver equipment and thdr control agnals. 

(2). Non-DAMA Mode. All members of a given Non-DAMA Mode 
OTCIXS n rf network shall; 

(a) . Transmit on the same assigned uplink frequency and recdve 
downlink broadcasts on the same translated downlink frequency. UHF uplink trananissions 
sutgect user baseband data to differentially encoded Biphase Phase Shift Keyed (BPSK) 
modulation. Appropriate donodulation is applied to the copied downlink broadcast. 

(b) . Transmit data to, and recdve data from, an ANAVSC-3(V) or 
ANAVSC-5(V) UHF radio transcdver. The half-duplex mode of operation shall be used. 

a Signal Timing and Sequaidng. 

The timing and sequaidng of the Phyacal Laya agnals in DAMA and 
Non-DAMA mode opoations are presented in the following subparagraphs. 

(1). DAMA Mode. Figure 5-2 illustrates the physical laya* signals 
employed by the OTCDCS II Link ControDa in the DAMA mode of operation. The timing 
and sequendng of these agnals (for anNCB) is shown in Figures 5-3 through 5-6. Figures 5-3 
through 5-6 are representative of timing requirements and are not to scale. 

(a). Transmisaon. Transmisaons shall be synchronized with the 
recdpt of the STM from the DAMA multiplexa, which is genaated by that device every 
1.38667 seconds. Transmission of basdiand data from an OTCIXS n station must commence 
1.38667 seconds (one DAMA frame time) before that baseband data is burst on the uplink. A 
TD-1271B/U usa may transmit continuously over sevoal fiame times; the continuity of the 
transmission is preserved as the recdved data is presented at each TD-1271B/U usa port. The 
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OTCIXS n subscriber equipment inventory does not allow a transmittmg platform to recdve 
its own transmission or even to be aware of baseband transmisaons initiated at the preceding 
Slot Time. The OTCIXS n Link Controller shall initiate DAMA Mode TU Transmission by 
asserting External Transmit Request (to the TD-1271B/U DAMA multiplexer) followed by 


Crypto PREP (to the KG-84A cryptogrjqihic unit). 



Figure 5-2. DAMA Configuration Physical Signals 


Upon receipt of Crypto PREP, the KG-84A will execute an alarm check sequence, generate its 
preamble, and forward that preamble to the OTCIXS II Link Controller as Transmit Data 
Black. The OTCIXS n Link Controller shall then forward the received crypto preamble to the 
TD-1271B/U as Transmit Data. The OTCIXS II Link Controller shall delay sending its 
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transmit data, as Transmit Data Red, to the KG-84 A to allow time for the KG-84A to 


complete execution of its alarm check sequence and generation of its preamble. This delay 
must be at least 289 ms (347 bit times) when a 1200 bps baseband rate is used and at least 152 


ms (364 bit times) when a 2400 bps baseband rate is used. Upon receipt of the transmit data 
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Figure 5-3. DAMA Configuration Physical Signal Timimg: 1200 pbs KG-84A Transmit 
the KG-84A will encrypt it and forward it to the OTCIXS n Link Controller as Transmit Data 
Black. The OTCIXS n Link Controller shall then forward the encrypted data to the 
TD-1271B/U as Transmit Data. 

(b). Reception. The OTCKS n Link Controller shall initiate DAMA 
Mode TU Reception upon receipt of SIGACQ fi-om the TD-1271B/U. Upon receipt of 
Receive Data fi-om the TD-1271B/U, the OTCKS II Link Controller shall forward the 
recdved data to the KG-84A as Receive Data Black. Upon detection of a crypto preamble, 
the OTCIXS n Link Controller shall prepare to receive the transmitted TU. After the KG-84A 
has achieved synchronization with the transmitting KG-84A it will begin decrypting the TU. 
The decrypted data is then forwarded by the KG-84A to the OTCIXS II Link Controller as 
Receive Data Red. 

From the perspective of downlink broadcast reception, net cycle slots 
are offset approximately 260 milliseconds (average uplink/downlink propagation time) from the 
uplink burst and approximately 1.65 seconds from the onset of a baseband transmission from 
an OTCIXS II Link Controller to its connected TD-1271B/U. One complete DAMA frame is 
lost whenever a station switches from a receiving to a transmitting stance. Hence, one frame is 
always lost after the NCB is transmitted. At least one, and occasionally two, frames are lost 
after each STTS. 

(2). Non-DAMA Mode. Figure 5-7 illustrates the physical layer 
sign?ik employed by the OTCIXS n Link Controller in the Non-DAMA mode of operation. 
The timing and sequencing of these signals (for an NCB) is shown in Figures 5-8 through 5-11. 

(a). Transmission, The OTCIXS n Link Controller shall initiate 
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Non-DAMA Mode TU transmission by asserting Keyline to the ANAVSC-3/5 transceiver. 

Immediately following Keyline assertion, the OTCIXS11 Link Controller shall assert 
Crypto PREP to the cryptographic unit. 

Upon receipt of Crypto PREP, the /jrypto will generate its preamble (an alarm check 
sequence will also be executed if the crypto is a KG-84A) and pass it to the OTCIXS 11 
Link Controller as Transmit Data Black. The OTCIXS II Link Controller shall then 
forward the received crypto preamble to the ANAVSC-3/5 as Transmit Data. After a 
baseband rate and crypto-type dependent delay following assertion of Crypto PREP (to 
allow for transmission of the crypto preamble), the OTCIXS II Link Controller shall 
begin sending its transmit data to the crypto as Transmit Data Red. When the crypto is a 
KG-84A, this delay must be at least 152 ms 

(364 bit times) when the baseband rate is 2400 bps or 80 ms (381 
bit times) when the baseband rate is 4800 bps. Upon receipt of the transmit data, the 
crypto will encrypt it and forward it to the OTCIXS II Link Controller as T ransm it Data 
Black, The OTCIXS II Link Controller shall then forward the encrypted data to the 
AN/WSC-3/5 as Transmit Data. 

(b). Reception. The OTCIXS II Link Controller shall initiate 
Non-DAMA Mode TU Reception upon receipt of Channel Busy from the AN/WSC-3/5 
transceiver. Upon receipt of Receive Data from the AN/Wl^C-3/5, the OTCIXS II Link 
Controller shall forward the received data to the crypto as Receive Data Black. Upon 
detection of a crypto preamble, the OTCIXS 11 Link Controller shall prepare to receive 
the transmitted TU. After the crypto has achieved synchronization with the transmitting 
crypto, it will begin decrypting the TU. The decrypted data is then forwarded by the 


72 




crypto to the OTCIXS n Link Controller as Receive Data Red 



Figure 5-4. DAMA Configuration Physical Signal Timing; 1200 bps KG84A Receive 
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Figure 5-5. DAMA Configuration Physical Signal Timing: 2400 bps KG-84A Transmit 























Figure 5-6. DAMA Configuration Physical Signal Timing; 2400 bps KG-84A Recdve 





















Figure 5-7. Non-DAMA Configuration Physical Signals 
d. Crypto Error Handling, 

Upon receipt of Crypto Alarm Indicate, the OTCIXS n Unk 
Controller shall attempt to clear the indicated alarm condition by asserting Crypto Alarm 
Reset to crypto. The crypto will respond by attempting to take itself out of the alarm 
state. If the crypto can clear the alarm condition, it will remove the Crypto Alarm Indicate 
signal. If the crypto carmot clear the condition, the OTCIXS 11 Link Controller will 
reassert Crypto Alarm Reset. If three consecutive attempts to clear the alarm condition 
are unsuccessful, the OTCIXS II Link Controller shall report the interface as inoperable 


and continue attempting to clear the alarm. 
2. Data Link Layer. 
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The OTCIXS n data link layer shall provide reliable data flow between the physical 
and network layers. It shall organize an outgoing (uplink) broadcast data structure into a 
sequence of 100-byte packets and supervise the output of each packet as an emitted bit stream. 
It shall also reassemble an incoming downlink bit stream into bytes, then packets, and 
finally into the original transport entity that was broadcast. Each Data Link Layer packet shall 
be 100 bytes in length and, as illustrated in section 7, contain the following components: 

a. END — a 1-bit flag indicating whether the packet is the final packet of a multipacket 
transmission. 

b. r.OTTNT — a 7-bit value indicating the number of data bytes centred in the packet. 
Legal values are 1 through 97. For multipacket transmissions, all packets except the final 
packet. 

c. INFOT? M AITTON — an array of "Byte Count" bytes of data containing part or all of 

aTU. 

d. CRC - a 2-byte CRC sequence computed over the Transmission End, Byte Count, 
and Data components of the packet. The CRC may be computed by software or by the 
ZILOG SIO hardware in the OTCIXS n Link Controller. The algorithm used to calculate the 
CRC is presented in Appendix B. shall contain 97 bytes. The final packet may contain from 1 
through 97 bytes. 

The Data Link layer shall provide limited error control by computing CRC values 
for, and appending those values to, each outgoing (uplink) packet. As packets are 
reassembled from the incoming (downlink) data stream, CRC values shall be computed 
and compared with those appended to the packets. Each packet for which the values 
match shall be considered error-free. Each packet for which the values do not match shall 
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Figure 5-8. Non-DAMA Configuration Physical Signal Timing: 2400 bps KG-84A Tr ansmit 























































Figure 5-9. Non-DAMA Configuration Phyacal Signal Timing: 2400 bps KG-84A Recdve 
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'Rgure 5-10. Non-DAMA Configuration Physical Signal Timing: 4800 bps KG-84A Transmit 
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Figure 5-11. Non-DAMA Configuration Phyacal Signal Timing: 4800 bps Recdve 


be flagged as containing errors. Each received packet, without regard to the presence or 
absence of errors, shall be forwarded to the network layer. 
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3. Networii Layer. 

The Networic Layer shall provide the management control under which orderly and 
reliable exchange of user information is permitted to occur. It involves the exchange of 
control, request, and subscriber data information between net members. The Network Layer 
assembles subscriber messages into STUs for transmission and extracts than from STUs 
received from the satellite downlink broadcast. Outgoing and incoming subscriber messages 
are passed between the Network Layer and the Transport Layer. The Transport Layer is 
beyond the scope of this document. 

a. Net Cyde Structure. The network layer partitions channel time into an 
unbounded sequence of units called "net cycles". The same basic net cycle structure is 
employed for both DAMA and Non-DAMA modes of operation witii dif^ences bang limited 
to timing details. Each net cycle is subdivided into an internal structure consisting of various 
cx>mbinations of the following: 

1. C . TS -- This time slot is used by the NCS for transmission of the NCB 
to all net members to initiate a net cycle and convey information about the current net 
cycle. 

2. RATS ~ This time slot is used by net members, on a contention basis, for 
transmission of RRTUs. The RATS is always present and conasts of a set of subintervals call 
Request Slots OE^S). Except during net initialization, there are three RSs, identified as RSI 
through RSS, in the RATS. During net initialization, there are eight RSs, identified as RSI 
through RSS, in the RATS. 

3. STTS — This time slot is used by net members for transmission of STUs 
(X)ntain]ng subscriber messages. The STTS is present only when a subscriber transmission has 
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been authorized by the NCS. 

Replicate transmissions of data in these time slots shall be used to increase 
the probability that each net member, including the NCS, will receive at least one copy of 
whatever is being broadcast. Moreover, in the case of STUs, multiple transmissions with 
selective packet replacement increases the probability that net members can reconstruct 
error-free composite copies of transmitted subscriber data. The NCB and RR 
transmissions per cycle shall depend upon the operating mode and baseband transfer rate 
as shown in Table 5-1. The STU transmissions per cycle shown in Table 5-1 represent 
default values for each combination of net mode and baseband rate. The actual times that 
a STU will be transmitted shall be specifiable by the net member in the range of one to 
three. 

b. Net Cycle Initiadan. 

Each net qrcle shall be initiated by transmission of an original and from zero to 
one copies of the NCB created by the NCS. The transmission shall be preceded by a fresh 
crypto preamble, and, in the case of the Non-DAMA operating mode, a fresh modem 
preamble. Critical information conveyed by the NCB shall be triply NCB shall be conveyed 
over the link in (i.e., as a passenger in) a single OTCIXS n packet. Each encoded and 
receiving net members shall consider the contents of a critical information field to be valid 
when two out of the three decoded values are equal. Each information field of the NCB is 
treated separatefy. 
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Table 5-1. TU Transmissions per Net Cycle 


Mode 

Baseband Rate 

.TUI 

fransmissions per Cvcle 

Nrp 

PR 

^TTT 

DAMA 

1200 bps 

1 

1 

2 

DAMA 

2400 bps 

1 

2 

2 

Non-DAMA 

2400 bps 

2 

2 

2 

Non-DAMA 

4800 bps 

2 

2 

3 


Hence, the presence of bit errors in a received NCB shall not cause that NCB to be 
rejected. The NCB shall include the following critical information fields: 

1. QD-Identifies the TU as an NCB 

2. COPY - Identifies which copy of the NCB has been received 

3. RATS TYPE - Identifies the type of RATS supported in this net cycle 

4. NCSLSTD - Identifies the subscriber functioning as NCS 

5. GRAN I 'KD STD - Identifies the subscriber (if any) to whom STTS has been 

allocated 

6. XMTT CT - If STTS has been allocated to a subscriber in this net cycle, 
identifies the number of times that subscriber is to transmit a STU in the STTS 

7. FT ASH ST GTS - Indicates the number of Flash precedence RSs in this net 

cycle’s RATS 

8. IMMRDTATF. SLOTS - Indicates the number of Immediate precedence 
RSs in this net cycle's RATS 

9. MODE - Identifies the type of service provided during this net cycle 

10. SB STATUS - Indicates the status of scheduled broadcasting during 
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this net cycle 


11. WINDOW ST7F. - Indicates the size of the window, in net cycles, to be 
used by net members in predicting their network service requirements 

12. HITS - Indicates the number of net cycles, within the window specified by 
the WINDOW SIZE field, in which a net member must receive at least one message for 
transmission in order to predict a network serwce requirement. 

In addition, the NCB shall include the current LAQ which identifies all 
outstanding subscriber requests for network services. The NCB shall also indude ^stem time 
and, when appropriate, STU acknowledgments. 

c Net Cyde Types. 

OTCIXS n shall provide two Q^cle types; Idle and Busy. 

(1) . Idle Cycle. An idle cycle shall conast of a CTS and a RATS. No 
SITS is present. Idle cycles occur only when there are no pending subscriber requests for 
network service. Figure 5-12 illustrates the gaieric structure of the idle cycle and its use. 

(2) . Busy Cycle. A busy cycle shall cxrnsist of a CTS, a RATS, and an 
sirs. A buy cycle occurs as the result of the NCS authorizing a net member to transmit an 
STU in that cycle. Figure 5-13 illustrates the generic structure of the busy cycle and its use. 

d. Net Cycle Tuning. 

The detailed time structure of net cycles with respect to DAMA and 
Non-DAMA mode operations is presented in the following paragraphs. 

(1). DAMA Mode. DAMA mode net cycle time slot events shall be 
synchronized on STM signals asserted by the TD-1271B/U Multiplexer. Individual 
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Figure 5-12. Idle Cycle Structure and Use 

NOTES: 1. Each "transmission” shown may actually involve multiple physical transmissions - each 
preceded by all required preambles. The number of physical transmissions to be performed is dependent 
on the selected net operating mode (DAMA/Non-DAMA) and baseband data rate as shown in Table 5-1. 

2. NCS transmits an NCB in the CTS to initiate the net cycle. The RATS TYPE field of this 
NCB indicates "Normal RATS". 

3. Station 1 determines that it has an STU to send, randomly selects RS3, and sends an RRTU in 
RS3 of the RATS to indicate its transmission requirement 

4. Station 2 determines that it has an STU to send, randomly selects RSI, and sends an RRTU in 
RSI of the RATS to indicate its transmission requirement. 


transmissions involve integral numbers of DAMA fi'ames of 1.38667 seconds duration. The 
CTS occupies one DAMA fi*ame as does each RS in the RATS. The STTS can occupy more 
than one DAMA fi-ame. DAMA Mode timing details regarding the CTS, RATS, and STTS 
are illustrated in Figures 6-14,6-15, and 6-16 respectively. From these figures it can be seen 
that the minimum net cycle length in DAMA Mode operation is 6 DAMA fi*ames (1 for CTS, 
1 for CTS guard, 3 for RATS, and 1 for End of Cycle (EOC) guard) or 8.32 seconds 
regardless of baseband rate. Assuming a busy cycle with three transmissions of a maximum 


86 






Figure 5-13. Busy Cycle Structure and Use 


NOTES: 1. Each "transmission" shown may actually involve multiple physical transmissions - each preceded by 
all required preambles. The number of physical transmissions to he performed is dq)endent on the selected net 
operating mode (DAMATNon-DAMA) and baseband data rate as shown in Table 5-1. 

2. NCS transmits an NCB in the CTS to initiate the net cycle. The RATS TYPE field of this NCB field 
indicates "Normal RATS". 

3. Station 1 determines that it has an STU to send, randomly selects RS2, and sends an RRTU in RS2 
of the RATS to indicate its transmission requirement. 

4. Station 2 determines that it is the GSID, the station authorized by NCS to transmit an STU in the 
SITS of the current net cycle, and commences transmission of an STU. The requirement to transmit this STU 
was identified by station 2 through transmission of an RRTU in the RATS of a previous net cycle. That RRTU 
also identified the number of times the subscriber intends to transmit the STU. 

5. If the GSED is the NCS, there will be a RATS Guard slot following RS3 (DAMA only). 


length STU, the maximum net cycle length is 115.09 seconds (83 DAMA frames) at a 
baseband rate of 2400 bps and 220.48 seconds (159 DAMA frames) at a baseband rate of 
1200 bps. 

(2). Non-DAMA Mode. Since there is no buffer delay in the rf 
uplink subsystem in the Non-DAMA operating mode, baseband data appears at receiving 
stations after the uplink/downlink propagation delay. Since STM signals are not available, 
each station must use a periodic (hardware) interval timer to track a cyclers structure. 
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Non-DAMA mode timing details regarding the CTS, RATS, and STTS are illustrated in 
Figures 5-17, 5-18, and 5-19 respectively. From these figures it can be seen that the 
minimum net cycle length in Non-DAMA Mode operation (regardless of baseband data 
rate) is approximately 6.4 seconds when the KG-84A is used. Assuming a busy cycle with 
three trans-missions of a maximum length STU, the maximum net cycle length in 
Non-DAMA Mode operations is approximately: 

(a) . 112.44 seconds when a KG-84A is used with a 2400 bps 

baseband rate 

(b) . 59.70 seconds when a KG-84A is used with a 4800 bps 

baseband rate 

C COMMUNICATION CONVENTIONS. 

The following subparagraphs describe the s)mchroni 2 ation and data transfer 
techmques net members shall employ to accomplish timely and orderly exchange of 
subscriber data. 

1. Net Participation Modes. 

Each member of an OTCIXS 11 net may participate in one of two roles; as the 
NCS or as a subscriber. 

a. Net Consol Station. 

Each member of an OTCDCS 11 rf net, with the exception of submarine 
subscribers, shall, in addition to performing subscriber functions, be capable of functioning 
as NCS for that net. Two precedence levels are accommodated: Flash and Immediate. 
NCS shall provide service to Flash RRs before servicing Immediate RRs. Requests for 
scheduled broadcasts shall be treated as having no precedence prior to the requested 
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BUSY 



Where Tq,, Tncb, Tpd, Txmii, and Tc^ are defined, in seconds, as follows; 


KG-84A 

Baseband Rate (bps) 

1200 

2400 

Tq> [KG-84A preamble + BISYNC code] 


0.20 

Tncb [NQ3 transmisaon time] 


0.33 

Tpd [propagationdelay (±0.01 sec)] 

0.28 

0.26 

N [number of transmisaons per cycle] 

1 

2 

Txniit=Tep+Tnd.+Tpd [total transmisaon time] 

1.26 

1.26 

Tcb [CTS duration = 1 DAMA frame] 

1.38667 

1.38667 


Figure 5-14. DAMA Mode OTCIXSE Timing-CIS 
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Where Tcp, Tteq, Tpd, Txmit, and Tis are defined, in seconds, as follows: 


KG-84A 

Baseband 1 

Rate (bosl 

1200 

2400 

Tcp [KG-84A preamble + BISYNC code] 


0.20 

Treq [RR transmission time] 


0.06 

Tpd [propagation delay (+0.01 sec)] 

0.28 

0.28 

N [number of transmissions per cycle] 

1 

2 

Txmit=N*(Tq>+Treq)+Tpd [total transmission time] 

.73 

.78 

Trs [RS duration = 1 DAMA firamel 

1.38667 

1.38667 


Figure 5-15. DAMA Mode OTCIXS H Timing - RATS 
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Where Tq>, Tstu, Tpd, Tjonit, and Tstts are defined, in seconds, as follows: 


KG-84A 

Baseband Rate (hosl 


1200 

2400 

Tcp [KG-84A preamble + BISYNC code] 

0.35 

0.20 

Tsto [max. length STU transmission time] 

70.00 

35.00 

Tpd [propagation delay (+0.01 sec)] 

0.26 

0.26 

N [number of transmissions per cycle] 

2 

2 

Txmit=N*(Tcp+Tstu)+Tpd [total transmission time] 

140.88 

70.58 

Tstts [STTS duration (DAMA fi-ames)] 

141.44 (102) 

70.72(51) 


Figure 5-16. DAMA Mode OTCIXS n Timing — STTS 
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Where Tq,, Tmod, Tncb, Tpd, Txmit, and Tcts are defined, in seconds, as follows: 


KG-84A 


Tcp [KG-84A preamble + BISYNC code] 

Tmod [modem preamble] 

Tncb [NCB transmission time] 

Tpd [propagation delay (+0.01 sec)] 

N [number of transmissions per cycle] 
Txmit=N*(Tcp+TmDd+Tncb)+Tpd [total xmit Tcts time] 
rCTS duration! 


Baseband Rate 


1200 2400 



Figure 5-17. Non-DAMA Mode OTCEXS H Timing - CTS 
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Where Tmod, Tq,, Treq, Tpd, N, Txmit, and Tb are defined, in seconds, as follows: 


KG-84A 

Baseband 

Rate (bps) 

1200 

2400 

Tmod [modem preamble] 

0.23 

0.12 

Top [KG-84A preamble + BISYNC code] 

0.23 

0.12 

Tieq [RR transmission time] 

0.06 

0.03 

Tpd [propagation delay (±0.01 sec)] 

0.26 

0.26 

N [number of transmissions per cycle] 

2 

2 

Txinit=N*(Tcp+Tmod+Treq)+Tpd [total xmit time] 

1.46 

1.31 

Tb [RS duration] 

1.60 

1.60 


Figure 5-18. Non-DAMA Mode OTCIXS n Timing - RATS 









Where Tcp, Tmod, Tstu, Tpd, N, Txmit, and Tstts are defined, in seconds, as follows: 


KG-84A 

Baseband Rate 

1200 

Tcp 

[KG-84A preamble + BISYNC code] 

0.16 


Tmod 

[modem preamble] 

0.10 


Tstu 

[max length STU transmission time] 

35.00 


Tpd 

[propagation delay (±0.01 sec)] 

0.26 


N 

[number of transmissions per cycle] 

2 


T3anit=N*(Tq,+Tmod+Tstu)+Tpd [total xmit time] 



W 

rSTTS duration] 




Figure 5-19. Non-DAMA Mode OTCIXS n Timing - STTS 













broadcast time and as having a precedence level between Flash and Inunediate thereafter. 
The OTCDCS n network protocol is not influenced by the type of subscriber data 
exchanged over the link. 

(1) . SID of the NCS net member serving as NCS shall: 

(a). Maintain the following control information, updating as 
necessary during net operations, and include it in the NCB it transmits to initiate each net 
cycle. 

(2) . Current network time 

(3) . SID of the net member, if any, that is authorized to transmit a 
STU in the STTS of the current net cycle and the number of times that STU is to be 
transmitted 


(4). Number of Flash and Inunediate RSs in the RATS of the 


current net cycle 


(5). Type of service provided during the current net cycle, as 


follows: 

(a) . Nonscheduled transmission of Flash precedence STU 

(b) . Nonscheduled transmission of Immediate precedence STU 

(c) . Scheduled broadcast STU transmission 

(d) . No STU transmission 

(6). Parameters to be used by net member in predicting service 

requirements 


follows: 


(7). Scheduled broadcasting status during the current net cycle, as 
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(a) . Scheduled broadcast activity this cycle 

(b) . Scheduled broadcast activity for this cycle delayed by Flash 

transmission 

(c) . Scheduled broadcast activity for this cycle preempted 

(d) . No scheduled broadcast activity this cycle 

(8) . Acknowledgments for the last three STUs transmitted by net 

members 

(9) . The list of RRs, previously submitted by net subscribers, that 
are awaiting service. This list, called the LAQ, contains a maximum of 21 RRs each 
consisting of 

(a) . SID of the subscriber requesting authorization to transmit an 

STU 

(b) . Type of STU transmission to be performed 

(1) . Nonscheduled transmission of Flash precedence STU 

(2) . Nonscheduled transmission of Immediate precedence 

STU 

(3) . Scheduled broadcast STU transmission 

(4) . Predicted nonscheduled transmission of Immediate 

precedence STU 

(c) . Minute past the hour at which scheduled broadcast is to be 
performed (scheduled broadcast transmissions only) 

(d) . Number of times the subscriber has requested its STU be 

transmitted. 
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(b) . Receive RRs from other net members and, following validation, queue 
and acknowledge those requests. RR validation shall consist of 

(1) . Identifying the entity received as an RR by means of its CID 

value. 

(2) . Constructing error-free values for each item of critical 
information contained in the request. Each such item is triply encoded and its contents is 
considered valid when two out of the three decoded values are equal. 

(c) . Selectively authorize, on an FCFS within precedence basis, net 
members to transmit subscriber data, in STUs, on the net. 

(d) . Transmit subscriber data, in STUs, to other net members. The member 
providing the Net Control Function shall indicate a requirement to transmit an STU by 
creating an entry at the end of the LAQ, within precedence, rather than broadcasting via 
the satellite link. 

(e) . Receive subscriber data, in STUs, from other net members. 

(f) . Detect and report Dual NCS conditions indicated by reception of 
NCBs from another net member. 

b. Subscriber. 

Each OTCIXS n net member other than the one serving as NCS 
participates in the net as a subscriber only. In this role the net member shall; 

a. Receive NCBs sent by the NCS to initiate net cycles. In so doing, the 
net member shall: 

(1) . Maintain net cycle synchronization 

(2) . Detect and report changes in the NCS SID and net initial- 
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ization sequences 


(3) . Detect and report the absence of Net Control if more than 16 
seconds elapse without receipt of a recognizable NCB or STU 

(4) . Determine when it is permitted to transmit RRs or subscriber 

data 

(5) . Receive system time from the NCS and, when validated, 
update its time accordingly 

(6) . Receive NCS acknowledgments for previously submitted RRs 

(7) . Mmntain the current contents of the LAQ. 

(b) . Receive subscriber data, in STUs, from other net members in STUs 

(c) . Transmit RRs to NCS 

(d) . Transmit subscriber data, in STUs, to other net members when 
specifically authorized by NCS to do so. 

2. Initialization/Startup. 

Whenever a net startup occurs, the NCS shall initiate an Extended RATS. As 
illustrated in Figure 5-20, the Extended RATS consists of eight consecutive idle cycles, 
each having an eight RS RATS. During the Extended RATS, any slot may be used for the 
transmission of RRs vwthout regard to the precedence of the traffic to be transmitted. 

On net initialization, the first cycle's NCB shall have a RATS TYPE field value of 
one and specify an eight RS RATS. Net members requiring net services shall transmit 
RRs in the Extended RATS as follows: 

a. The net cycle, in the Extended RATS, in which to transmit shall be determined 
by random selection. 
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b. The RS, in the previously identified net cycle, in which to transmit shall be 
determined by random selection. 

3. RATS Management. 

The RATS portion of the OTCIXS n net cycle supports the submission of RRs to 
the NCS by net subscribers. Except as discussed under initialization/startup, the RATS 
for a net cycle shall contain three RSs; RSI, RS2, and RS3. NCS shall designate each of 
these slots as a Flash Slot, reserved for Flash precedence RRs, or an Immediate Slot, 
reserved for Immediate precedence and Scheduled Broadcast RRs. To support NCS 
reception of Flash precedence requests prior to Immediate precedence requests, RSs 
designated as Flash Slots shall occur, in the RATS, prior to those designated as Immediate 
Slots. NCS designation of RSs shall be based on the type of activity that is to take place 
during that cycle: 

a. During a busy net cycle in which Flash traffic is to be transmitted in the STTS, 
there shall be two Flash Slots and one Immediate Slot. 

b. During a busy net cycle in which Immediate traffic is to be transmitted in the 
STTS, there shall be one Flash Slot and two Immediate Slots. 

c. During an idle net cycle, there shall be one Flash Slot and two Immediate Slots. 
The number of Flash Slots and Immediate Slots in a net cycle is indicated in the NCB sent 
by the NCS to initiate that cycle. 

4. Link Access Request Submission. 

The following subparagraphs provide details of the techniques used by net 
members to submit their transmission requirements to the NCS. 
a. KRTU. 
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A net member not authorized to transmit during the current net cycle's 
STTS shall initiate a request for link access by transmitting an RRTU in an RS of the 
RATS in a single OTCIXS n data link layer packet. A net member with Flash precedence 
traffic to transmit shall use a Flash Slot to identify its transmission requirements to the 
NCS. If more than one Flash Slot is available, the net member shall randomly select one. A 
net member with Immediate precedence or scheduled broadcast traffic to transmit shall 
use an Immediate Slot to identify its transmission requirements to the NCS. If more than 
one Immediate Slot is available, the net member shall randomly select one. A net member 
with traffic to transmit shall not transmit an RRTU if: 

1. An RR for nonscheduled STU transmission at the same precedence 
level previously submitted by that member is present in the LAQ 

2. The net member is currently executing the CRA described in paragraph 

6.3.6. 

member is awaiting service with respect to a previously sent RR for Immediate traffic. 

b. Piggyback RR 

A net member authorized to transmit during the current net cycle's STTS 
may indicate one additional request for link access by piggybacking an RR in space 
provided in the STU format. By doing so, the net member may submit its request without 
risk of contention with other members. In this way it is possible for a net member to 
request and be granted authorization to transmit STUs on a continuing basis. Piggyback 
requests may result from existing or predicted service requirements and can be used even 
if the net member is. A net member may, however, submit an RR for Flash traffic even 
though that currently executing the CRA described in paragraph C.6 
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(1). Existing Senace Requirements. An existing service 
requirement shall exist when the net member granted authorization to transmit a STU: 

(a). Has more messages than a single STU can accommodate. In 
this case, the net member may use the STUs piggyback request structure to indicate: 



Figure 5-20. Extended RATS Structure and Use 


NOTES: 

1. Each "transmission" shown may involve multiple physical transmissions -each preceded by all 
required preambles. The number of physical transmissions to be performed is dependent on the selected 
net operating mode (DAMA\Non-DAMA) and baseband data rate as shown in Table 5-1. 

2. NCS transmits a NCB in the CTS to initiate the first cycle of the extended RATS. The RATS 
TYPE field of this NCB field indicates "Initial Net C^cle of Extended RATS." 

3. Station 1 determines that it has an STU to send, randomly selects Cycle 1 of the Extended 
RATS, and them randomly selects RS8 of the cycle. Since C^cle 1 of the Extended RATS was selected, 
station 1 sends an RRTU in RS8 of the RATS of the current net <ycle. 

4. Station 3 fteter mitifts that is has an STU to send, randomly selects Cycle 2 of the Extended 
RATS, and then randomly selects RSI of that cycle. Station 3 now awaits for reception of the NCB 
initiating the second cycle of the Extended RATS and sends an RRTU in RSI of the RATS of the net 
cycle. 
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5. Station 2 detemunes that is has an STU to send, randomly selects Cycle 8 of the Extended 
RATS, and then randomly selects RS8 of that <ycle. Station 2 now waits for reception of the NCB 
initiating the eighth cycle of the Extended RATS and sends an RRTU in RS8 of the RATS 
of that net cycle. 


(1) . Additional transmission required for nonscheduled broadcast. 

(2) . Additional transmission required for the current scheduled 

broadcast. 


This request will be queued for service exactly like any other 
request and, as a result, consecutive tycle allocations cannot be guaranteed. 

(b). Identifies the next time at which a STU is to be delivered by 

scheduled broadcast. 

(2). Predicted Service Requirements. A predicted ser\dce 
requirement shall exist when the net member granted authorization to transmit a STU 
predicts that an additional nonscheduled broadcast transmission requirement is likely to 
exist in the near future. This prediction is based on the number of messages that became 
available for transmission by that net member during the preceding net cycles. If at least 
one message became available for transmission by the net member in at least M of the 
immediately preceding N net cycles, that net member shall use the STUs piggyback 
request structure to indicate a predicted service requirement. Values of M and N to be 
used by the net members in their service requirement predictions are provided by the NCS 
in the HIT and WINDOW fields, respectively, of each NCB. If M=2 and N=16, for 
example, a predicted service requirement would exist if at least one message became 
available for transmission by the net member during 2 or more of the preceding 16 net 
cycles. 
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5. Link Access Request Reception. 

To receive RR forwarded by net members, the NCS shall copy all RRTUs 
transmitted during the RATS and, for the purpose of identifying piggyback RRs, all STUs 
transmitted during the STTS. RRs shall be validated and processed based on the type of 
service requested. As previously indicated, the LAQ shall contmn up to 21 entries each 
indicating an RR, previously submitted by a net member, that is awaiting service. Of these 
entries, 19 shall be used for RRs without regard to service t 5 q)e requested. While these 19 
entries are full, the NCS shall discard RRs that do not indicate nonscheduled transmission 
of Flash precedence STU. Two entries in the LAQ shall be reserved exclusively for RRs 
indicating nonscheduled transmission of Flash prece-dence STU. 

Each RR made by a net member shall be acknowledged by NCS through inclusion 
of the net member's SID in the LAQ which is provided in the NCB. If a net member does 
not observe its SID in the LAQ in the next NCB, the request collided with a request 
submitted by an-other net member in the same RS or no entries in the LAQ were available 
to support the type of service requested. In either event, the net member shall execute the 
CRA described in paragraph 6.3.6. 

a. Nonscheduled Transmission of Flash Precedence STU. 

If an RR indicating a requirement for nonscheduled transmission of a Flash 
precedence STU is received, the NCS shall examine the LAQ for the net member 
submitting the request to determine if an entry for that member currently exists. If one 
does not exist, an entry shall be created that contains the newly received RR. If an entiy 
already exists and that entry indicates: 

1. Nonscheduled transmission of Flash precedence STU, the NCS shall 
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discard the newly received RR as a duplicate. 

2. Scheduled Broadcast STU transmission, the NCS shall create an entry 
for the newly received RR. 

If the RR was submitted by piggyback and indicated a predicted service 
requirement, the NCS shall delay entering the request in the LAQ for one net cycle. This 
delay improves the likelihood that the subscriber predicting a service requirement will have 
a message ready for transmission when the NCS selects the request from the LAQ. 

b. Nomcheduled Transmission of Immediate Precedence STU. 

If an RR indicating a requirement for nonscheduled transirrission of an 
Immediate precedence STU is received, the NCS shall examine the LAQ for the net 
member submitting the request to determine if an entry for that member currently exists. 

If one does not exist, an entry shall be created that contains the newly received RR. If an 
entry already exists and that entry indicates: 

1. Nonscheduled transmission of Immediate precedence STU, the NCS 
shall discard the newly recdved RR as a duplicate. 

2. Scheduled Broadcast STU transmission, the NCS shall create an aitry 
for the newly received RR. If the RR was submitted by piggyback and indicated a 
predicted service requirement, the NCS shall delay entering the request in the LAQ for 
one net cycle. This delay improves the likelihood that the subscriber predicting a service 
requirement will have a message ready for transmission when the NCS selects the request 
from the LAQ. 

a Scheduled Broadcast STU Transmission STU. 

If an RR indicating a requirement for scheduled broadcast STU 
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transmission is received, the NCS shall examine the LAQ for the net member submitting 
the request to determine if a scheduled broadcast entry for that member already exists. If 
an entry already exists, the broadcast minute from the new request shall replace the 
broadcast minute of the LAQ entry. If an entry does not exist, the NCS shall create an 
entry in the LAQ for the newly received Scheduled Broadcast request. 

6. Contention Resolution Algorithm. 

When more than one net member transmits an RR in the same RS, the resulting 
collision is referred to as contention for that given RS. When a net member transmitting 
an RR fails to locate its SID in the LAQ included in the next cycle's NCB, contention has 
occurred and that net member must execute a CRA. The CRA consists of randomly 
selecting the number of net cycles the member must delay prior to retransmitting the RR. 
For RRs involving nonscheduled transmission of Flash precedence STU, the range of 
cycles to delay shall be 0-7 cycles. For all other RRs, the range of cycles to delay shall be 
0-15. If the net member is granted authorization to transmit an STU prior to completion 
of the CRA, the CRA shall be terminated if the net member is able to piggyback the RR 
involved to that STU. 

7. Link Access Request Servicing. 

Prior to the initiation of each net cycle, the NCS shall examine the contents of its 
LAQ to identify if any RRs are awaiting service. If not, the NCB sent by the NCS to 
initiate the next net cycle shall indicate an idle cycle with no STU transmission and mark 
the scheduled broadcast status as not active. In addition, the contents of the GSID field of 
that NCB shall indicate that no net member has been authorized to transmit in the STTS. 

If at least one RR is present, NCS shall; 
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a. Examine each RR in the LAQ requesting scheduled broadcast STU 
transmission. NCS shall: 

1. Purge those that were not serviced within 45 seconds of their indicated 
transmission time and mark the scheduled broadcast status of the next net cycle as 
preempted by Flash traffic. 

2. Mark as avmlable for servicing any such request whose indicated 
transmission time has just arrived. 

b. Attempt to service a Flash request. If at least one is present, the NCS shall 
mark the next net cycle as nonscheduled transmission of Flash precedence STU and select 
the Flash request that has been in queue the longest for service. The NCS shall identify 
the net member submitting that request as authorized to transmit in the STTS of the next 
net cycle and purge the request from the LAQ. If at least one scheduled broadcast request 
is marked as available for servicing, the NCS shall mark the scheduled broadcast status of 
the next cycle as delayed by Flash traffic. If not, the NCS will mark the scheduled 
broadcast status of the next cycle as not active. 

c. If no Flash requests are present, attempt to service a scheduled broadcast 
request. If at least one is present that is marked as available for servicing, the NCS shall 
mark the next net cycle as scheduled broadcast STU transmission and select the scheduled 
broadcast request that has been in queue the longest for service. The NCS shall identify 
the net member submitting that request as authorized to transmit in the STTS of the next 
net cycle and purge the request from the LAQ. The NCS shall also mark the scheduled 
broadcast status of the next net cycle as active. 

d. If no Flash requests or scheduled broadcast requests marked as available for 
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servicing are present, attempt to service an Immediate request. If at least one is present, 
the NCS shall mark the next net cycle as nonscheduled transmission of Immediate 
precedence STU and select the Immediate request that has been in queue the longest for 
service. The NCS shall identify the net member submitting that request as authorized to 
transmit in the STTS of the next net cycle and purge the request from the LAQ. The NCS 
shall also mark the scheduled broadcast status of the next net cycle as not active. 

e. If no request can be serviced this net cycle, mark the next net cycle as an idle 
cycle with no STU transmission and mark the scheduled broadcast status as not active. In 
addition, the NCS shall indicate that no net member has been authorized to transmit in the 
STTS of the next net cycle. 

The NCS shall allocate exactly one STTS per RR. The NCB initiating a busy net 
cycle shall identify the net member to whom the STTS is allocated, the number of times 
the STU will be transmitted, the type of service provided during the net cycle, and the 
status of scheduled broadcasting during the net cycle. Only that net member to whom the 
cycle is allocated shall be permitted to transmit in the STTS and the sequence of 
transmissions, once begun, cannot be preempted. 

8. Subscriber Data Transmission. 

When a net member receives an NCB identifying its SID as the authorized 
transmitter during the STTS of the current net cycle, the net member shall compose its 
STU and commence transmission of that STU within 2 seconds of the onset of the STTS. 
STU composition and transmission shall be performed as follows: 

a. The net member shall determine the type of transmission being authorized 
during this net cycle from the MODE fiel(J of the NCB initiating the cycle. 
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b. If no Transport Layer messages are available for transmission, an empty STU 
shall be composed and transmitted. 

c. The net member shall determine which of the Transport Layer messages 
avmlable for transmission are to be included in this STU as follows, 

1. Flash precedence STU transmission authorized. Flash precedence 
messages shall be selected for inclusion on a FIFO basis. Message selection shall continue 
until all Flash precedence messages have been selected or the space available in the STU 
for conveying Network messages has been exhausted. 

2. Immediate precedence STU transmission authorized. Message selection 
shall depend on whether any Flash precedence messages are available for transmission, as 
follows: 

(a) . Flash precedence messages available. Flash precedence 
messages shall be selected for inclusion on a FIFO basis. Message selection shall continue 
imtil all Flash precedence messages have been selected or the space available in the STU 
for conveying Network messages has been exhausted. An RR shall be piggybacked in the 
STU to re-request transnussion authorization for the Immediate precedence messages 
whose transmission was deferred. 

(b) . Flash precedence messages not available. Immediate 
precedence messages shall be selected for inclusion on a FIFO basis. Message selection 
shall continue until all Immediate precedence messages have been selected or the space 
available in the STU for conveying Network messages has been exhausted. 

d. Each Transport Layer message selected for inclusion in the STU shall be 
incorporated into a Network message and a BSN shqll be assigned to that message for 
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identification. BSNs shall be assigned sequentially to support link accountability and 
identification of missed messages. 

e. The Network messages resulting from the preceding step shall be assembled 
into the STU. A Message Pointer Block shall be constructed to define, explicitly, the 
starting positions of each Network message in the STU. Due to the critical nature of its 
contents, the Message Pointer Block shall be terminated by a PCS. The PCS shall be a 
CRC sequence calculated as described in Appendix B. 

Net mranbers receiwng this STU shall use the PCS to validate the contents of the 
Message Pointer Block and, as a result, their ability to delimit the Network messages in 
the STU properly. 

f If an existing or predicted service requirement exists, the net member shall 
piggyback an RR to the STU. To accomplish this, the RESV field of the STU shall 
indicate the presence of such a requirement. The MODE field shall identify the type of 
service request being piggybacked to this STU, and the XMIT CT field shall indicate the 
number of times the STU in the piggybacked RR is to be broadcast. If the requested 
service is scheduled broadcast STU transmission, the TRANSMIT MINUTE shall indicate 
the minute within the hour at which the scheduled broadcast is to occur. 

g. The MORE field of the STU shall indicate a requirement for additional net 
services under the current broadcast if 

1. The STU under construction is to be transmitted by scheduled 

broadcast 

2. More messages are available for transmission on the broadcast than can 
be accommodated in a single STU 
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3. The total amount of transmit time on the scheduled broadcast, including 
the services being indicated in this request, will not exceed five minutes. 

h. The STU shall be forwarded to the Data Link Layer for decomposition into a 
series of 100-byte data link packets and transmission via the assigned satellite channel. 

The STU shall be transmitted in its entirety and, in most instances, transmitted up to two 
more times in succession in this net cycle; the actual number of repeats is an 
operator-selectable option. The COPY field in each transmission shall uniquely identify 
each transmission of the STU in the STTS. 

A special situation arises when the station transmitting a STU is also the 
designated NCS. In such instances, the NCS shall delay at least 500 milliseconds before 
initiating the next net cycle to accommodate uplink/dovmlink propagation and provide 
time for net members to finalize the STU reception process and prepare to receive the next 
cycle's NCB. 

9. Subscriber Data Reception. 

Each net member, including NCS, copying the downlink STTS broadcast shall 
attempt to reconstruct an error-free composite copy of the STU from the incoming packet 
stream using selective packet replacement when more than one transmission of the STU in 
the STTS has been performed. As soon as an error-free composite copy has been 
constructed or all transmissions of the STU have been received, processing of the STU 
shall commence as described in the following subparagraphs. 

a. Subscriber. 

Each member participating in the net as a subscriber shall; 

1. Attempt to validate the triply encoded CID and SID fields of the STU. 


110 



Since the CID field of the STU identifies the type, and hence stracture, of the received 
TU, the received STU shall be discarded if the CID field cannot be validated. If validation 
of the SID field is achieved and the SID is equal to the receiver's SID, a Dual SID alert 
shall be generated. 

2. Attempt to validate the contents of the Message Pointer Block in the 
STU by calculating a CRC on its fields, exclusive of the PCS field, and comparing it to the 
contents of the PCS field. The algorithm used to calculate this CRC is described in 
Appendix B. If a match is not obtained, the STU shall be discarded since the individual 
network messages in the STU cannot be properly delimited. 

3. If the contents of the Message Pointer Block is valid, each network 
message in the STU shall be extracted and forwarded to the Transport Layer. 

b. Net Control Station. 

In addition to performing all processing required for the Subscriber 
participation mode, the member serving as theNCS shall acknowledge receipt of the STU, 
Attempt to allocate additional net cycles to net members performing scheduled broadcast 
STU transmission when necessary to complete that broadcast and identify and process an 
RR piggybacked to the STU. 

(1). STU Acknowledgment. To acknowledge receipt of an STU 
via the downlink broadcast, the NCS shall update its control information as follows; 

(a) . The SID of the net member shown in the STU 3 Acknowledge 
field of the NCB transmitted in the preceding net cycle shall be discarded. 

(b) . The SID of the net member shown in the STU 2 Acknowledge 
field of the NCB transmitted in the preceding net cycle shall be placed in the STU 3 
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Acknowledge field of the next NCB to be sent. 


(c) . The SID of the net member shown in the STU 1 Acknowledge 
field of the NCB transmitted in the preceding net cycle shall be placed in the STU 2 
Acknowledge field of the next NCB to be sent. 

(d) . The SID of the net member transmitting the received STU 
shall be placed in the STU 1 Acknowledge field of the next NCB to be sent. If the SID 
field of the received STU could not be validated, the STU 1 Acknowledge field will 
indicate that no subscriber is being acknowledged. 

(2). Scheduled Broadcast Continuation. If the received STU was 
transmitted by scheduled broadcast and the MORE field of the STU indicates that 
additional service is required for STU transmission on the current broadcast schedule, the 
NCS shall examine its LAQ and: 

(a) . If no Flash precedence RRs are present and if less than 5 
minutes (maximum) have elapsed since the onset of the first net cycle allocated to this 
scheduled broadcast. The NCS shall authorize the net member indicated in the SID field to 
continue the scheduled broadcast in the next net cycle. NCS shall indicate this 
authorization by using the net member's SID in the GSID field in the next NCB to be sent. 

(b) . If a Flash precedence RR is present or if more than 5 minutes 
have elapsed since the onset of the first net cycle allocated to this scheduled broadcast, the 
NCS shall reject the request for scheduled broadcast continuation. The NCS shall notify 
the requesting net member of the rejection by setting the SB STATUS field in the next 
NCB to be sent to indicate that scheduled broadcasting has been preempted. In addition, 
net members monitoring the scheduled broadcast shall determine fi-om the preemption 
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indication that the scheduled broadcast has ended. 

(3). Piggyback Request Identification. To support submission of 
RRs via STU piggyback, the NCS shall: 

(a) . If the SID field of the STU could not be validated, discontinue 
processing of the STU for purposes of identifying piggybacked service requests. 

(b) . When the criteria described in paragraph C.9.2.2 are met, 
support continuation of a net member's scheduled broadcast. 

(c) . If the RESV field indicates the presence of a piggybacked RR, 
attempt to validate the triply encoded MODE, TRANSMIT MINUTE, and XMIT CT 
fields of the STU. Since these fields identify the characteristics of the requested net 
service, processing of the STU for purposes of identifying piggybacked service requests 
shall be discontinued if any of these fields cannot be validated. If these fields are 
validated, the RR shall be added to the LAQ as discussed in the Link Access Request 
Reception description. 

10. Transfer of NCS Responsibilities. 

The OTCIXS n protocol contains no provisions for transferring NCS 
responsibilities automatically. The role of NCS is assumed or relinquished on operator 
command under direction of Fleet and Theater commanders. Each net member capable of 
assuming the role of NCS copies and maintains the current LAQ sent by the current NCS 
in each received NCB. This process provides the necessary information to each net 
member to enable that member to assume the role of NCS and resume net operations 
without performing the regular net initialization sequence. 
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VI. DATA UNIT DESCRIPTIONS 


A. GENERAL. 

This section provides a detailed description of the contwit and format of the signals 
exchanged between OTCDCS n subscribers. Each description consists of a figure, pictorially 
representing the position of the various fields, fijUowed by a table explaining and clarifying each 
field. All numbers are in hexadecimal unless specified othavrise. L^al values are identified 
for each field which does not permit the full range of legal values represented by the field. 

Fields which do not include the idaitification of legal values can contain any value which can be 
represented by the field ^e (i.e., a byte can contain values 0 throu^ FF). 


B. DATA UNIT DESCRIPTION - NET CONTROL STATION TO SUBSCRIBER 

Table 6-1 summarizes the data units transferred fi'om the OTCIXS n NCS and an OTCDCS n 
subscriber. 


Table 6-1. Net Control Station to Subscriber Data Unit Summary 


DATA UNIT NAME 

COMPONENT 

ID 

FIGURE 

Net Control Block (NCB) Transmission Unit (TU) 

B 

6-1 

Sifirscriber Transmission Unit (STU) 

D 

6-3 

Network Message 

- 

6-4 

Data Link Layer Packet 

- 

6-5 
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C DATA UNIT DESOOPTION - SUBSCRIBER TO NET CONTROL STATION. 
Table 6-2 summarizes the data units transferred from an OTCDCS n subscriber to the 
OTCKSENCS. 


Table 6-2. Subscriber to Net Control Station Data Unit Summary 


DATA UNIT NAME 

COMPONENT 

ID 

FIGURE 

Reservation Request (RR) Transmission Unit 

C 

6-2 

(RRTU) 

D 

6-3 

Subsaiber Transnrisaon Unit (STU) 

■- 

6-4 

Network Message 

- 

6-5 

Data Link Layer Packet 




D. DATA UNIT DESCRIPTION - SUBSCRIBER TO SUBSCRIBER. 

Table 6-3 summarizes the data units transferred from one OTCIXS n subscriber to another 
OTCIXS n subscriber. 


Table 6-3. Subscriber to Subscriber Data Unit Summary 



COMPONENT 


DATA UNIT NAME 

ID 

HGURE 

Subscriber Transraisaon Unit (STU) 

D 

6-3 

Network Message 

- 

6-4 

Data Link Layer Packet 

- 

6-5 
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BIT POSITIONS 


B 

Y 

T 


E 

7 1 6 

5 

4 1 

3 2 

1 0 

0 

CID 

COPY 

RATS TYPE 

1 


COPY 

RATS TYPE 

2 

CID @5 

COPY@l 

RATS TYPE @ 1 

3 

NCS SID (LSBl 

4 

NCS SID ILSBl 

5 

NCSSID(LSB)@55 

6 

NAJ 

NCS SID (MSB) 

7 

N/U 

NCS SID (MSBl 

8 

NAJ 

NCS SID (MSB) @ 15 

9 

I NAJ 

HOURS 

A 

NAJ 

MINUTES 

S 

NAJ 

SECONDS 

C 

TIMEOIECKSUM 

D 

GRANTED SID (GSID) (LSB) 

E 

GRANTED SID (GSID) (LSB) 

F 

GRANTED SID (GSID) (LSB) @ 55 

10 

NAJ 

GRANTED SID (GSID) (MSB) 

11 

NAJ 

GRANTED SID (GSID) (MSB) 

12 

NAJ 

GRANTED SID 1 

[GSID) (MSB) @ 15 

13 

XMITCT 

FLASH SLOTS 

IMMEDIATE SLOTS 

14 

XMITCT 

FLASH SLOTS 

IMMEDIATE SLOTS 

15 

XMITCT @1 

FLASH SLOTS @ 2 

IMME 

DIATE SLOTS @ 5 

16 

MODE 

SB STATUS 

HITS 

WINDOW SIZE 

17 

MODE 

SB STATUS 

HITS 

WINDOW 5I3i 

18 

MODE @ 1 

SB STATUS @ 1 

HITS@1 

WINDOW SIZE @1 


Figure 6-1. Net Control Block (NCB) Transmission Unit 
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BIT POSITION 


B 

Y 

T 

E 



7 6 

5 4 3 2 1 0 

19 

STU 1 ACKNOWLEDGE (LSB) 

lA 

N/U 

STU 1 ACKNOWLEDGE (MSB) 

IB 

STU 2 ACKNOWLEDGE (LSB) 

1C 

N/U 

STU 2 ACKNOWLEDGE (MSB) 

ID 

STU 3 ACKNOWLEDGE (LSB) 

IE 

N/U 

STU 3 ACKNOWLEDGE (MSB) 

IF 

NCSLAQSIZE 

20 

NCSLAQ 
(see description) 

0 

0 

0 

N 


BYTE 

FIELD 

DESCRIPTION 

0 

RATS TYPE 

Identifies the type of RATS supported in this net cycle as 

(bits 0-1) 


follows: 



0 - Normal RATS 

1 - Initial net cycle of extended RATS 

2 - Intermediate net cycle of extended RATS 

3 - Final net cycle of extended RATS 

0 

COPY 

Indicates which copy of the NCB has been received; i.e., 1 

(bits 2-3) 


is the first transmission, 2 is the second transmission. Legal 
values are 1 through 2. 

0 

CID 

Indicates the NCB data unit. Value is always hexadecimal 

(bits 4-7) 


B. 

1 

(bits 0-1) 

RATS TYPE 

One's conq>lement of the RATS TYPE field. 

1 

(bits 2-3) 

COPY 

One's complement of the COPY field 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


1 

(bits 4-7) 


One's complement of the CID field 

2 

(bits 0-1) 

RATS TYPE @ 1 

Exclusive OR of the RATS TYPE field with L 

2 

(bits 2-3) 

COPY@l 

Exclusive OR of the COPY field with 1. 

2 

(bits 4-7) 

CID@5 

Exclusive OR of the CID field with 5. 

3 

NCSSID(LSB) 

Contains the LSB of the Net Control Station (NCS) ID. Legal 
values of NCS SID are 0001 through 9999 (decimal). 

4 

NCSSID(LSB) 

One's complement of the NCS SID (LSB) field 

5 

NCS SID (LSB) 
@55 

Exclusive OR of the NCS SID (LSB) field with hexadecimal 55. 

6 

(bits 0-5) 

NCS SED (MSB) 

Contains the MSB of the Net Control Station (NCS) ID. Legal 
values of NCS SID are 0001 through 9999 (decimal). 

/ 

(bits 0-5) 

NCS SID (MSB) 

One's complement of the NCS SID (MSB) field 

8 

(bits 0-5) 

NCS SID (MSB) 
@15 

Exclusive OR of the NCS SID (MSB) field with hexadecimal 

15. 

9 

(bits 0-4) 

HOURS 

Hour component of the current time as maintained by NCS. 

Legal values are 0 through 23 (decimal). 

A 

(bits 0-5) 

MINUTES 

Minute component of the current time as maintained by NCS. 
Legal values are 0 through 59 (decimal). 

B 

(bits 0-5) 

SECONDS 

Second component of the current time as maintained by NCS. 
Legal values are 0 through 59 (decimal). 

C 

TIME 

CHECKSUM 

The least significant bits of the one's complement of the 
checksum of the HOURS, MINUTES, and SECONDS fields. 
Compute as; 



(((SECONDS + MINUTES) x 2) + HOURS) x 2 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 


119 









BYTE, 

FIELD 

DESCRIPTION 

. D 

GSID(LSB) 

Contains the LSB of the SID of the subscriber that has been granted 
the next STTS. Values of0001 through 9999 identify a subscriber. 

A value of zero indicates that no subscriber has been assigned the 
STTS. 

E 

GSIDO-SB) 

One's complement of the GSID (LSB) field. 

F 

GSID(LSB)@ 

55 

Exclusive OR of the GSID (LSB) field with hexadecimal 55. 

10 

Contains the MSB of the SID of the subscriber that has been granted 

(bits 0-5) 

GSID (MSB) 

the next STTS. Values of0001 through 9999 identify a subscriber. 

A value of zero indicates that no subscriber has been assigned the 

11 


STTS. 

(bits 0-5) 

GSID (MSB) 

One's complement of the GSID (MSB) field. 

12 

bits 0-5) 

GSID (MSB) 

Exclusive OR of the GSID (MSB) field with hexadecimal 15. 


@15 


13 


Indicates the number of Immediate RSs in the current net cycle. 

(bits 0-5) 

IMMEDIATE 

These slots follow all Flash precedence RSs in the RATS. This field 


SLOTS 

is ignored except when the RATS TYPE field indicates Nonnal 

RATS. 

13 

FLASH 

Indicates the number of Flash precedence RSs in the RATS of the 

(bits 0-2) 

SLOTS 

current net cycle. These slots precede all Immediate precedence RSs 
in die RATS. This field is ignored except when the RATS TYPE 
field indicates Normal RATS. 

13 


Indicates the number of times the subscriber designated by the GSID 

(bits 6-7) 

XMITCT 

field is to transmit a STU in the STTS. Value range is one through 
three. A value of zero is illegal and shall be treated as one. 

14 

IMMEDIATE 

One's complement of the IMMEDIATE SLOTS field. 

(bits 0-2) 

SLOTS 

14 

(bits 3-5) 

FLASH 

SLOTS 

One's complement of the FLASH SLOTS field. 

14 

(bits 6-7) 

XMITCT 

One's complement of the XMTT CT field. 


Figure 6-1. Net Control Block (NCR^Transmission Unit (cont.) 






BYTE 


FIELD 


DESCRIPTION 


15 

(bits 0-2) 

IMMEDIATE 
SLOTS @ 5 

Exclusive OR of the IMMEDIATE SLOTS field with 
hexadecimal 5. 

15 

(bits 3-5) 

FLASH 
SLOTS @ 2 

Exclusive OR of the ELASH SLOTS field with hexadecimal 2. 

15 

(bits 6-7) 

XMTTCT® 

1 

Exclusive OR of the XMTT CT field with 1. 

16 

(bits 0-1) 

WINDOW 

SIZE 

Identifies the size of the window, in net cycles, to be used by 
netwoik subscribers in jnedicting their network service 
recjuirements. Legal values are as follows; 



0-12 net cycles 

1 - 16 net cycles 

2 - 20 net cycles 

3-24 net cycles 

16 

(bits 2-3) 

HITS 

Identifies the minimum number of net cycles, within the 
window specified by the WINDOW SIZE field, in which a net 
member must receive at least one message for transmission in 
order to predict a network service requirement. Legal values are 
as follows; 



0 - 2 net cycles 

1 - 3 net cycles 

2 - 4 net cycles 

3 - 5 net cycles 

16 

(bits 4-5) 

SB STATUS 

Indicates the scheduled broadc^asting status during this net 
cycles as follows; 



0 - Scheduled broadcast activity this cycle 

1 - Scheduled broadcast activity for this cycle delved by Flash 

transmission 

2 - Scheduled broadcast activity for this cycle preempted 

3 - No scheduled broadcast activity this cycle 

16 

(bits 6-7) 

MODE 

Identifies the type of service provided during this net cycle as 
follows; 



0 - Nonscheduled transmission of Flash precedence STU 

1 - Nonscheduled transmission of Imme^te pocedence STU 

2 - Scheduled broadcast STU transmission 

3 - No STU transmission 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 
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BYTE 

FIELD 

DESCRIPTION 




17 

(bits 0-1) 

WINDOW 

SIZE 

One's complement of the WINDOW SIZE field 

17 

(bits 2-3) 

HITS 

One's complement of the HITS field 

17 

(bits 4-5) 

SB STATUS 
@1 

One's complement of the SB STATUS field 

17 

(Wts6-7) 

MODE 

One's complement of the MODE field 

18 

(bits 0-1) 

WINDOW 

SIZE@1 

Exclusive OR of the WINDOW SIZE field with 1. 

18 

(tats 2-3) 

HITS@1 

Exclusive OR of the HITS field with 1. 

18 

(tats 4-5) 

SB STATUS 
@1 

Exclusive OR of the SB STATUS field with 1. 

18 

(bits 6-7) 

MODE @ 1 

Exclusive OR of the MODE field with 1. 

19 

STUl 

AQCNOWLE 

DGE(LSB) 

Contains the LSB of the SID of the subscriber that transmitted 
an STU one net cycle prior to this one. Indicates that NCS 
received the STU sent that subscriber. Values of0001 
through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged A value of zero indicates that no subscriber is 
being acknowledged 

lA 

(bits 0-5) 

STUl 

ACKNOWLE 
DGE (MSB) 

Contains the MSB of the SID of the subscriber that transmitted 
an STU one net cycle prior to this one. Indicates that NCS 
received the STU sent by that subscriber. Values of0001 
through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged A value of zero indicates that no subscriber is 
being acknowledged 

IB 

STU2 

ACKNOWLE 
DGE (LSB) 

Contains the LSB of the SID of the subscriber that transmitted 
an STU two net cycles prior to this one. Indicates that NCS 
received the STU sent by that subscriber. Values of0001 
through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged A value of zero indicates that no subscriber is 
being acknowledged 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


1C STU2 Contains the MSB oftheSDDofthe subscriber that transmitted 

(bits 0-5) ACKNOWLE an STU two net cycles prior to this one. Indicates that NCS 

DGE(MSB) received the STU sent by that subscriber. Values of 0001 

through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged. A value of zero indicates that no subscriber is 
being acknowledged. 

ID STU 3 Contains the LSBofthe SID ofthe subscriber that transmitted 

ACKNOWLE an STU three net cycles prior to this one. Indicates that NCS 
DGE(LSB) received the STU sent by that subscriber. Values of 0001 

through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged. A value of zero indicates that no subscriber is 
being acknowledged 

IE STU 3 Contains the MSB ofthe SID ofthe subscriber that transmitted 

(bits 0-5) ACJCNOWLE an STU three net cycles prior to this one. Indicates that NCS 
DGE(MSB) received the STU sent by that subscriber. Values of0001 

through 9999 (decimal) indicate the SID of the subscriber being 
acknowledged A value of zero indicates that no subscaiber is 
being acknowledged 


NCSLAQ 

SIZE 


NCSLAQ 


Indicates the number of subscribers that are awaiting 
assignment of link time for STU transmissions; that is, the 
number of entries in the LAQ. The queue can contain up to 21 
(decimal) entries. 

The SIDs of the subscribers currently awaiting assignment of 
link time for STU transmissions. The length of this qpieue is 
given by the contents of the NCS LAQ SIZE field Each entry 
in the NCS LAQ consists of three bytes defined as follows: 


.BIT position: 


110 


m+2 1 XMITCT 


TRANSMIT MINUTE 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 
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BYTE 

FIELD 

DESCRIPTION 

20-K (cont.) 

NCSLAQ 

(cont.) 

1 

Where: 

SDD (LSB) is the LSB of the subscriber SID 

SID (MSB) is the MSB of the subscriber SID. SIDs 0001' 
through 9999 (decimal) identify networic subscribers. 

MODE identifies the type of entry as follows: 

0 - Nonscheduled transmission of Flash precedence 

STU 

1 - Nonscheduled transmission of Inunediate 

precedence STU 

2 - Scheduled broadcast STU transmission 

3 - Predicted nonscheduled transmission of Immediate 

precedence STU. 

TRANSMIT MINUTE is the minute within the hour at which 
scheduled broadcast by this subscriber is to commence. Field is 
not interpreted when &e MODE field of the queue entry 
indicates a nonscheduled broadcast. 

XMIT CT is the number of times the subscriber has requested 
its STU be broadcast. Range of values is one throng three. A 
value of zero is illegal and shall be treated as one. 


Figure 6-1. Net Control Block (NCB) Transmission Unit (cont.) 
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BIT POSITIONS 


B 

Y 

T 


JL> 

7 6 

5 4 

3 2 

1 0 

0 

CID 

COPY 

N/U 

1 

CED 

COPY 

N/U 

2 

CID@5 

COPY@l 

N/U 

3 

SID (LSB) 

4 

SID (LSB) 

5 

SID (LSB) @55 

6 

MODE 

SID (MSB) 

7 

MODE 

SID (MSB) 

8 

MODE @ 1 

SID (MSB) @ 15 

9 

XMTTCT 

TRANSMIT MINUTE 

A 

XMTTCT 

TRANSMIT MINUTE 

B 

XMITCT@1 

TRANSMIT MINUTE @ 15 

C 

RETRY COUNT 

D 

RETRY COUNT 

E 

RETRY COUNT @ 55 


BYTE 

FIELD 

DESCRIPTION 

0 

(bits 2-3) 

0 

(bits 4-7) 

COPY 

Indicates which copy of the RR has been received; Le., 1 
is the first transmission, 2 is the second transmission 

Legal values are 1 through 2. 

CID 

Indicates the RR data unit. Value is always hexadecimal 

C. 

1 

(bits 2-3) 

COPY 

One’s complement of the COPY field. 

1 

(bits 4-7) 

CID 

One's complement of the CID field. 


Figure 6-2. Reservation Request (RR) Transmission Unit 
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BYTE 


FIELD 
COPY @ 1 


_ DESCRIPTION 

Exclusive OR of the COPY field with 1. 


2 

(bits 2-3) 
2 

(bits 4-7) 
3 


4 


5 

6 

(Wts 0-5) 


6 

(bits 6-7) 


7 

(bits 0-5) 

7 

(bits 6-7) 

8 

(bits 0-5) 
8 

(bits 6-7) 
9 

(bits 0-5) 



SID (LSB) 
SID(LSB)@55 
SID (MSB) 

MODE 


SID (MSB) 

MODE 

SID (MSB) @ 15 
MODE @ 1 

TRANSMIT MINUTE 


Exclusive OR of the CID field with 5. 


Contains the LSB of the SID of the network subscriber 
that is requesting service. Legal values are 0001 
through 9999 (decimal). 


One's complement of the SID (LSB) field. 


Exclusive OR of the SID (LSB) field with hexadecimal 
55. 

Contains the MSB of the SID of the network subscriber 
that is requesting service. Legal values are 0001 
through 9999 (decimal). 

Indicates the type of service being requested as follows; 

0 - Nonscheduled transmission of Hash precedence 
STU 

1 - Nonscheduled transmission of Immediate 

precedence STU 

2 - Scheduled broadcast transmission of STU 
3-N/U 


One's complement of the SID (MSB) field. 


One's complement of the MODE field. 


Exclusive OR of the SID ^SB) field with hexadecimal 
15. 

Exclusive OR of the MODE field with 1. 


Indicates the minute within the hour at which a 
scheduled broadcast is to occur. Field is not interpreted 
when the MODE field indicates a nonscheduled 
broadcast. 


Figure 6-2. Reservation Request (RR) Transmission Unit (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


9 

(bits 6-7) 


XMTTCT 


Indicates the requested number of times that the STU is 
to be broadcast. Range of legal values is one throu^ 
three. A value ofzero is illegal and shall be treated as 
one. 


A 

(bits 0-5) 
A 

(bits 6-7) 


TRANSMIT 

MINUTE 


XMITCT 


One's complement of the TRANSMIT MINUTE field. 
One's complement of the XMTT CT field. 


B 

(bits 0-5) 


TRANSMIT 
MINUTE @15 


Exclusive OR of the TRANSMIT MINUTE field with 
hexadecimal 15. 


B 

(bits 6-7) 


XMITCT@ 1 


Exclusive OR of the XMTT CT field with 1. 


C 


D 


RETRY COUNT 


Indicates the number of times the subscriber attempted 
net entry, prior to acknowledgement of the request in the 


NCB. 


RETRY COUNT 


One's complement of the RETRY COUNT field. 


E 


RETRY COUNT @ 
55 


Exclusive OR of the RETRY COUNT field with 
hexadecimal 55. 


Figure 6-2. Reservation Request (RR) Transmission Unit (cont.) 
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B 

Y 

T 

E 

7 

6 

5 

BIT I 

4 

>OSITI 

3 

ONS 

2 

1 

0 

0 

CID 

COPY 

PREC 

RESV 

1 

CID 

COPY 

PREC 

RESV 

2 

CID@5 

COPY@l 

PREC 

RESV@1 

3 

SID(LSB) 

4 

SID (LSB) 

5 

SID(LSB)@55 

6 

MODE 

SID (MSB) 

7 

MODE 

SID (MSB) 

8 

MODE @ 1 

SID (MSB) @15 

9 

XMITCT 

TRANSMIT MINUTE 

A 

XMITCT 

TRANSMIT MINUTE 

B 

XMITCT @1 

TRANSMIT MINUTE @ 15 

C 

MORE 

0 

0 

0 

0 

0 

0 

0 

D 

MORE 

0 

0 

0 

0 

0 

0 

0 

E 

MORE 

0 

0 

0 

0 

0 

0 

0 

F 

0 

0 

0 

N 

MESSAGE POINTER BLOCK 

(see description) 

Ml 

0 

0 

0 

M2-1 

NETWORK MESSAGE 1 


Figure 6-3. Subscriber Transmission Unit 
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BIT POSITIONS 


B 

Y 

T 

E 


M2 


o 

o 

0 


Mn-l 


o 

o 


Mn 


o 

o 

o 


Mz 


NETWORK MESSAGE n 


BYTE 

FIELD 

DESCRIPTION 

0 

RESV 

Indicates the presence or absence of a "piggy-back” 

(bitO) 


reservation request in this STU. A value of one indicates 
a "piggy-back” reservation request is present; a value of 
zero indicates no such request is present. 

0 

PREC 

Indicates the precedence of the STU. A value of zero 

(bill) 


iadicates an Immediate precedence STU. A value of one 
indicates a Flash precedence STU. 

0 

(bits 2-3) 

COPY 

Indicates which copy of the STU has been received; i.e., 1 
is the first transmission, 2 is the second transmission, etc. 


Legal values are 1 through 3. 

0 

CID 

Indicates an STU. Value is always hexadecimal D. 

(bits 4-7) 



1 

RESV 

One’s complement of the RESV field. 

(bitO) 



1 

PREC 

One's complement of the PREC field. 

(bill) 




Figure 6-3. Subscriber Transmission Unit (cont.) 
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BYEE 


FIELD 


DESCRIPTION 


1 

(bits 2-3) 
1 

(bits 4-7) 
2 

(bitO) 

2 

(bitl) 

2 

(bits 2-3) 
2 

(bits 4-7) 


3 


4 


5 


6 

(bits 0-5) 


6 

(bits 6-7) 


COPY 

One's complement of the COPY field. 

CID 

One's complement of the CID field. 

RESV@1 

Exclusive OR of the RESV field with 1. 

PREC 

Duplicate of byte 0 (bit 1). 

COPY@l 

Exclusive OR of the COPY field with 1. 

CID @5 

Exclusive OR of the CID field with 5. 

SID(LSB) 

Contains the LSB of the SID of the netwoik subscriber 
originating the transmission. Legal values are 0001 
through 9999 (decimal). 

SID (LSB) 

One's complement of the SID (LSB) field. 

SID (LSB) @ 55 

Exclusive OR of the SID (LSB) field with hexadecimal 

55. 

SID (MSB) 

Contains the MSB of the SID of the netwoik subscriber 
originating the transmission. Legal values are 0001 
through 9999 (decimal). 

MODE 

Indicates the type of service request that is "piggy¬ 
backed" to this STU as follows: 


0 - Nonscheduled transmission of Flash 
precedence STU required 

1 - Nonscheduled transmission of Immediate 

precedence STU required 

2 - Scheduled Inoadcast transmission of STU 

required 

3 - Nonscheduled transmission of Immediate precedence 

STU predicted 


This field is not interpreted when the RESV field 
indicates that no "pi^-back" reservation request is 
present. 


Figure 6-3. Subscriber Transmission Unit (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


7 

(bits 0-5) 

SID (MSB) 

One’s complement of the SID (MSB) field 

7 

(bits 6-7) 

MODE 

One’s complement of the MODE field 

8 

(bits 0-5) 

SID (MSB) @ 15 

Exclusive OR of the SID (MSB) field with hexadecimal 

15. 

8 

(bits 6-7) 

MODE @ 1 

Exclusive OR of the MODE field with 1. 

9 

(bits 0-5) 

TRANSMIT 

MINUTE 

Indicates the minute within the hour at which a scheduled 
broadcast is to occur. This field is interpreted onfy when 
the RESV field indicate that a "piggy-back” reservation 
request is present and the MODE field indicates that 
Scheduled broadcast transmission of a STU is required 

9 

(bits 6-7) 

XMITCT 

Indicates the requested number of times the STU in the 
"piggy-back" reservation request is to be broadcast. 

Range oflegal values is one through three. A value of 
zero is illegal and shall be treated as one. 

A 

(bits 0-5) 

TRANSMIT 

MINUTE 

One’s complement of the TRANSMIT MINUTE field 

A 

(bits 6-7) 

XMITCT 

One’s complement of the XMTT CT field 

B 

(bits 0-5) 

TRANSMIT 
MINUTE® 15 

Exclusive OR of the TRANSMIT MINUTE field with 
hexadecimal 15. 

B 

(bits 6-7) 

C 

(bit 7) 

XMITCT® 1 

MORE 

Exclusive OR of the XMTT CT field with 1. 

Indicates if additional service is required for STU 
transmission on the current broadcast schedule. A value 
of one indicates service is required; a value of zero 
indicates no such requirement exists. 

D 

(bit 7) 

MORE 

One’s conq)lement of the MORE field 


Figure 6-3. Subscriber Transmission Unit (cont.) 
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BYTE 


FIELD 


DESCRIPTION 


E 

(bit?) 


MORE 


Duplicate of byte C (bit 7). 


F-N 


MESSAGE 
POINTER BLOCK 


Indicates the location of the start of the messages in the 
STU. The block is formatted as follows: 


B 



Where: 

MESSAGE COUNT is the number of network messages 
present in the STU. 


POINTER 1 ^SB) is the LSB of the location of the start 
of NETWORK MESSAGE 1 relative to the start of the 
MESSAGE POINTER BLOCK. 

POINTER 1(MSB) is the MSB of the location of the start 
of NETWORK MESSAGE 1 relative to the start of the 
MESSAGE POINTER BLOCK. 


Figure 6-3. Subscriber Transmission Unit (cont.) 
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BYTE 


EELD 


DESCRIPTION 


F-N (cont.) 


MESSAGE 
POINTER BLOCK 
(cont.) 


POINTER n (LSB) is the LSB of the location of the start 
of NETWORK MESSAGE n relative to the start of the 
MESSAGE POINTER BLOCK 


M1-(M2-1) 


POINTER n G'^SB) is the LSB of the check sequence 
calculated over the MESSAGE COUNT field and each of 
the MESSAGE POINTER fields. The algorithm used to 
calmlatfi the check sequence is defined in appendix B. 

PCS (LSB) is the LSB of the check sequence calculated 
over the MESSAGE COUNT field and each of the 
MESSAGE POINTER fields. The algorithm used to 
calculate the check sequence is defined in appendix B. 

PCS (MSB) is the MSB of the check sequence calculated 
over the MESSAGE COUNT field and each of the 
MESSAGE POINTER fields. The algorithm used to 
calculate the check sequence is defined in appendix B. 

NETWORK Contains network message numiber 1. 

MESSAGE 1 


Mn-Mz 


NETWORK 
MESSAC® n 


Contains network message number n. 


Figure 6-3. Subscriber Transmission Unit (cont.) 
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BIT POSITIONS 


B 

Y 

T 

E 



7 

6 

5 

4 3 

2 

1 

0 

0 

BSN(LSB) 

1 

BSN(MSB) 

2 








0 

0 

0 




TRANSPORT MESSAGE 



N 









BYTE 

FIELD 

DESCRIPTION 

0,1 

BSN 

Indicates the Broadcast Sequence Number (BSN) assigned 



to the TRANSPORT MESSAGE. Legal values are 0001- 



9999. 

2-N 

TRANSPORT 

Contains the Transport L^er messasge as specified in the 


MESSAGE 

TADKS IDS, Volume I. (Should be renamed to 



OTCDCS/TADIXS Transport Layer IDS). 


Figure 6-4. Network Message 
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B 

Y 

T 


BIT POSITIONS 



7 

6 

5 

4 3 

2 

1 

0 

0 

END 

COUNT 

1 








0 

0 




INFORMATION 




0 








61 








62 

CRC(LSB) 

63 

CRC (MSB) 


BYTE 

FIELD 

DESCRIPTION 

0 

(bits 0-6) 

COUNT 

Indicates the number of l^es in the INFORMATION field 
of the packet. With the excqition of the final packet of a 
multipacket sequence, the value of this field shall be 97 
(decimal) bytes. In the final packet of a multipacket 
sequence, legal values for this field are 1-97 (decimal) 
l^tes. 

0 

END 

Indicates if this packet is the final packet of a multipacket 
sequence. Value is 1 if this is the final packet; value is 0 if 
this is not the final packet. 

1-61 

INFORMATION 

Consists of a part or all of a network message. The length 
of this field is indicated the contents of the COUNT 

field. The INFORMATION field in all padcets except the 
last of a multipacket sequence shall be 97 (deciinal) bytes 
in length. The length of the INFORMATION field in 
final packet of a multipacket sequence is 1-97 (decimal) 
bytes. 

62 

CRC(LSB) 

Contains the LSB of the CRC. Calculated over the 

COUNT, END, and INFORMATION fields. TheORCis 
calculated using the polynomial algorithm contained in 
appendix B. 

63 

CRC OVISB) 

Contains the MSB of the CRC. (Calculated over the 
COUNT, END, and INFORMATION fields. The CRC is 
calculated using the polynomial algorithm contained in 
appendix B. 


Figure 6-5. Data Link Layer Packet Format 


135 




















TfflS PAGE INTENTIONALLY LEFT BLANK 


136 


APPENDIX A 


LIST OF ACRONYMS and ABBREVIATIONS 


Arrnnym 

Di^finitinii 

ADCCP 

Advanced Data Communications Control Procedure 

Ascn 

American Standard Code for Information Interchange 

BCS 

Block Check Sequence 

bps 

bits per second 

BPSK 

Bi-phase Phase Shift Keyed 

BSN 

Broadcast Sequence Number 

ccm 

International Telegraph and Telephone Consultative Committee 

CCS 

Combat Control System 

Cl 

Control Indicator 

CED 

Component Identification 

CMSA 

Cruise Missile Support Activity 

COMASWFOR 

Commander, Antisubmarine Warfare Forces 

COMSUBGRU 

Commander, Submarine Group 

COMSUBLANT 

Commander, Submarine Forces Atlantic 

COMSUBPAC 

Commander, Submarine Forces Pacific 

CONUS 

Continental United States 

CRA 

Contention Resolution Algorithm 

CRC 

Cyclic Redundancy Check 

CIS 

Contro;! Time Slot 


137 



Acronym 

DAMA 

DART 

DoD 

EASTPAC 

EOC 

ERCT 

ETCT 

FCDSSA 

FCFS 

FDDS 

FIFO 

FLTSA 

FOSIC 

FOSIF 

GRD 

GSID 

ID 

IDS 

IF 

10 

ISO 

KA^T 


ncfinifion 

Demand Assigned Multiple Access 
Dynamically Adaptive Receiver/Transmitter 
Department of Defense 
Eastern Pacific 
End of Cycle 

External Receive Ciphered Text 

External Transmit Ciphered Text 

Fleet Combat Direction Systems Support Activity 

First-Come, First-Served 

Flag Data Display System 

First-in, First-out 

Fleet Satellite 

Fleet Ocean Surveillance Information Center 
Fleet Ocean Surveillance Information Facility 
Guard 

Granted Subscriber Identification 
Identification 

Interface Design Specification 
Intermediate Frequency 
Indian Ocean 

International Standards Organization 
Ke 5 rboardATdeo Display Terminal 
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Armnym 

ni»finitinn 

LANT 

Atlantic 

LAQ 

Link Access Queue 

LEASAT 

Leased Satellite 

LSB 

Least Significant Byte 

MODS 

Mission Data Distribution System 

MED 

Mediterranean 

MIAR 

Message Indicate Alarm Reset 

MSB 

Most Significant Byte 

NCB 

Net Control Block 

NCS 

Network Control Station 

NCTAMS 

Naval Computer and Telecommunications Area Master Station 

NCTS 

Naval Computer Telecommunications Station 

NDF 

Network Description File 

NSDL 

Network Simulation Description Language 

N/U 

Not Used 

OSIS 

Ocean Surveillance Information System 

OTCIXS 

OflRcer in Tactical Command Information Exchange Subsystem 

OTH-T 

Over-the-Horizon Targeting 

OTH/DCT 

Over-the-Horizon Detection, Classification and Targeting 

PAC 

Pacific 

PCS 

Pointer Check Sequence 

PIO 

Parallel Input/Output 
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Afrnnym 

PREC 

RADCON 

RATS 

RDO 

RDl 

RED-AI 

REMCON 

RESV 

rf 

RP-STEYR 

RR 

RRTU 

RS 

RX-DPT 

SAT 

SATCOM 

SATS 

SB STATUS 
SID 

SIGACQ 

SIU 

SPAWARSYSCOM 


Definilion 

Precedence 

Radio Controller 

Random Access Time Slot 

Red Receive Data 

Crypto Receive Data 

Red Alarm Indicate 

Remote Controller 

Reservation 

Radio Frequency 

Remote Standby Red 

Reservation Request 

Reservation Request Transmission Unit 

Request Slot 

Receive Digital Plain Text 
Satellite 

Satellite Communications 
Single Access Time Slot 
Scheduled Broadcast Status 
Subscriber Identification 
Signal Acquired 
Sensor Interface Unit 

Space and Naval Warfare Systems Command 
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Arronym 

T>i»finition 

SSIXS 

Submarine Satellite Information Exchange Subsystem 

STM 

Slot Time Mark 

STT 

Shore Targeting Terminal 

STTS 

Subscriber Transmission Time Slot 

STU 

Subscriber Transmission Unit 

SYNC-CMD-TX 

Synchronize Command Transmit 

TADIXS A 

Tactical Data Information Exchange Subsystem A 

TBD 

To Be Determined 

TDO 

Crypto Transmit Data 

TDl 

Red Transmit Data 

TDDS 

Tactical Data Display System 

TDMA 

Time Division Multiple Access 

TDP 

Tactical Data Processor 

TDPCON 

Tactical Data Processor Controller 

TGF 

TADIXS Gateway Facility 

TGP 

TADIXS Gateway Processor 

TTY 

Teletype 

TU 

Transmission Unit 

TWCS 

Tomahawk Weapons Control System 

TX-DPT 

Transmit Digital Plain Text 

UHF 

Ultrahigh Frequency 

USCINCLANT 

United States Coimnander-in-Chief, Atlantic 
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Acronym 

USCINCPAC 

WESTPAC 

WPC 

XMITCT 


Pftfinifion 

Uxiited States Coinmander-in-Chief, Pacific 
Western Pacific 
Washington Planning Center 
Transmit Coimt 
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APPENDIX B 


CYCLIC REDUNDANCY CHECK SEQUENCE GENERATION 


A. GENERAL. This appendix defines the Cyclic Redundanqr Check (CRC) algorithm used 

by the data units of the OTCIXS n netwoik. The gaierator polynomial used in the CRC 
calculation is the polynomial defined by the hrtemational Telegr^h and Telephone 
Consultative Committee (CCITT) Recommendation V.41 and used in ANSI Standard X3.66 
for Advanced Data Communication Control Procedures (ADCCP). This genaator 
polynomial is: G(X) = x“ + + X^ + 1. 

B. CRC GENERATION ALGORITHM. The software algorithm which realizes this 
process is shown in Figure B-1. For convenience of implemaitation, and to permit high speed 
generation of the CRC, the algorithm has been designed to process one 8-bit byte at a time. 
Figure B-2 contains a listing of the algorithm as programmed for an 8080 microprocessor. 
Table B-1 provides samples from the CRC generation algorithm. 


Table B-1. Sample Inputs/Outputs For CRC Generator 


INPUT 

(Hexadecima 

0 

RESULT 

(Hexadecimal) 

fflBYIE 

LOBYTE 

ACCUMULATOR 

HIBYTE 

LOBYTE 

FF 

FF 

01 

FI 

D1 

FF 

FF 

00 

El 

FO 

FF 

FF 

80 

70 

78 

00 

00 

01 

10 

21 

00 

00 

80 

91 

88 

55 

55 

01 

4F 

71 

55 

55 

80 

CE 

D8 

55 

55 

55 

55 

00 

AA 

AA 

AA 

AA 

00 
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STEP OPERATION 


1 

A = Incoming Byte 

2 

I = CRCHI .XOR. A 

3 

A = I.RS.4 

4 

A = I.XOR. A 

5 

I = A 

6 

A = A.LS.4 

7 

A = A .XOR. CRCLO 

8 

J = A 

9 

A = I 

10 

A = A .RS . 3 

11 

A = A .XOR . J 

12 

CRCHI = A 

13 

A = I 

14 

A = A.LS. 5 

15 

A = A . XOR . I 

16 

CRCLO = A 


Where: 

A is an 8-bit accumulator register 
I and J are 8-bit scratch pad registers 
CRCHI is the high order 8 bits of the CRC 
CRCLO is the low order 8 bits of the CRC 
.XOR. is an 8-bit Exclusive OR operation 
.RS. is a right-shift 
•LS. is a left-shift 

Note: Right- and left-shifts "pull zeros," e.g., ABCDEFGH right-shifted 3 would 
produce 000ABODE. 

Initial value of CRCEDl and CRCLO is zero before applying this algorithm to data 
bytes in the data fi'ame. 


Figure B-1. CRC Generator Algorithm 
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CRC - ROUTINE TO CALCULATE THE CRC FOR 8080 MICROPROCESSOR. 

ON ENTRY, H = 

MSB OF CRC, L = LSB OF CRC, A = NEW BYTE; 

RESULT IS H = MSB OF NEW CRC, L = LSB OF NEW CRC. 

CRCiXRAH 

;EXCLUSIVE-OR CRC MSB AND ACCUM 

MOVD,A 

;STORE IN SCRATCHPAD 

RRC 

;SHIFT ACCUM RIGHT 4 

RRC 


RRC 


RRC 


ANIOFH 

;ACCUMULATOR NOW HAS OOOODKL 

XRAD 

;EXCLUSIVE-OR SCRATCHPAD AND ACCUM 

MOVD,A 

;RESULT IS DKLMNOP, SAVE IN SCRATCHPAD 

RLC 

;SHIFT ACCUM LEFT 4 

RLC 


RLC 


RLC 


ANIOFOH 

;ACCUM NOW HAS MNOPOOOO 

XRAL 

;XOR ACCUM AND LSB OF CRC 

MOVH,A 

;PUT RESULT IN MSB OF CRC TEMPORARILY 

MOVA,D 

;BRING BACK UKLMNOP TO ACCUM 

RRC 

;SHIFT ACCUM RIGHT 3 

RRC 


RRC 


ANIIFH 

;ACCUM NOW HAS OOODKLM 

XRAH 

pCORMSB OF CRC AND ACCUM 

MOVE, A 

;STORE RESULT AS NEW CRC MSB 

MOVA,D 

3RING BACK IJKLMNOP TO ACCUM 

RLC 

;SHIFT ACCUM LEFT 5 

RLC 


RLC 


RLC 


RLC 


ANIOEOH 

;ACCUM NOW HAS NOPOOOOO 

XRAD 

;XOR SCRATCHPAD AND ACCUM 

MOVL,A 

;RESULT IS NEW CRC LSB 

RET 

;EXIT SUBROUTINE 


Figure B-2. 8080 Listing of CRC Generator 
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APPENDIX C Section Cl 


OTCIXSII SIMULATION PREFORMANCE RESULTS 

A. PURPOSE. 

The Officer in Tactical Conunand Information Exchange Subsystem (OTCIXS) is 
an existing subsystem of the Navy Ultrahigh Frequency (UHF) Satellite Communications 
(UHF SATCOM) System that provides beyond line-of-sight automatic exchange of 
tactical messages between ships, submarines and shore facilities. Subscribers may 
exchange computer-to-computer formatted data (datalink) messages or teletype messages 
via the OTCIXS network. The OTCIXS network operates on a demand assign basis so 
that when a subscriber needs to transmit data, access to the network can be gained 
quickly. The OTCIXS network also provides for priority preemption so that subscribers 
with higher priority data can gain control of the network by interrupting the normal 
transmission of lower priority data. The current OTCIXS network functions well in the 
current mode; that is, without the use of multiplexing equipment. However, there is a 
limited ability to support all of the network subsystems that exist today 'with the limited 
hardware and satellite resources available. The increasing requirements for satellite 
communications links and the limited number of available satellite channels and 
transmit/receive equipment have led to the need for sharing available resources. This can 
be accomplished only by limiting the number of networks supported by a subscriber or by 
using multiplexing equipment. 

Early analysis indicates that the current OTCIXS network will not operate 
efficiently using the TD-1271 BAJ Demand Assigned Multiple Access (DAMA) 
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multiplexing equipment. This has necessitated the development of a proposed a new 
protocol for OTCIXS that will provide efficient performance for both non-DAMA and 
DAMA operations. This report describes the methods of analyzing the new proposed 
protocol for the OTCIXS network (hereafter referred to as OTCIXS II) for both non- 
DAMA and DAMA operations. The primary focus of this analysis is on message 
throughput times, queue wait times, message throughput rate, and network transmission 
utilization. These values are obtained for various scenario/exercises consisting of different 
combinations of total messages per hour generated by the simulation, different number of 
high and low priority network access request slots, and with and without automatic 
rescheduling of subscriber access to the network for data transmission. 

The different scenario/exercise parameters, as applicable, are used with both the 
OTCIXS I and OTCIXS 11 simulations to provide comparative results between the old 
and newly proposed protocols. The simulation program and network model are only 
approximations of real world operations but are providing both OTCIXS I and OTCIXS 
n simulation test results, at least a comparison of the newly proposed protocol to the old 
can be reasonably performed. The simulation of the newly proposed protocol will exhibit 
both the errors and deficiencies exhibited by the old; by providing results for both 
protocols, it is assumed that reasonable conclusions can be drawn from the simulation 
results. 

B. BACKGROUND. 

The increasing requirements for satellite communications links using limited 
number of available satellite channels have led to the development of DAMA which 
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permits several UHF SATCOM subsystems to share a single 25 kHz satellite channel. 
Either the Fleet Satellite (FLTSAT) or Leased Satellite (LEASAT) can be used for 
OTCIXS operations. A subscriber designated as a Net Control Station (NCS) coordinates 
the use of the OTICXS network. Surface ships and shore sites are capable of assuming 
the NCS function. The NCS receives, queues, and acknowledges receipt of subscriber 
access requests. The NCS assigns transmission times to all high priority (flash) requests, 
scheduled low priority (immediate) broadcast requests, and finally non-scheduled 
immediate requests. Once a subscriber has been authorized by the NCS to transmit its 
message data, the subscriber initiates message transmission; in the proposed OTCDCS11 
protocol, the subscriber will not be preempted by other message transmissions r^ardless 
of precedence of the message involved. 

DAMA divides channel transmission into 1.38667 second intervals called frames. 
Each frame is divided into burst transmission subintervals called slots. There are several 
groupings of slots within a frame; these are called frame formats. Frame formats consist 
of combinations of slots supporting user transfer-rate to DAMA burst-rate transmissions. 
User rates vary from 75 bits per second (bps) to 16,000 bps; DAMA bursts rates vary 
from 9,600 to 32,000 S 5 mibols per second. Some slots are dedicated for DAMA 
operations and are not available for general use. The rest of the transmission time in a 
frame is allocated to user slots. Each network is assigned a slot to use based on those 
available within the active frame format at the time the network is attached to DAMA. 

It was assumed that user networks can operate in a DAMA environment with little 
or no change to the program software. However, analysis of the OTCIXS network 
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indicates that this is not a correct assumption. A model of the OTCDCS network for non- 
DAMA and DAMA operations was developed to analyze OTCIXS performance. Results 
from this analysis show degraded operations in the DAMA environment. It is therefore 
anticipated that a new OTCIXS protocol would need to be defined to operate in the 
DAMA environment without suffering the degradation of the current network protocol. 
This analysis is an attempt to determine the performance characteristics of the newly 
proposed OTCIXS II protocol. Only the non-DAMA operation of the current OTCIXS 
network operations was analyzed since the DAMA operation has degraded performance, 
which the newly proposed protocol is intended to correct. 


C. NETWORK SIMULATION SUMMARY. 

The analysis of network performance used several different items of data to 
provide the various different simulations. These items included subscriber message queue 
wait times, message throughput times, message throughput rates, and network utilization. 
These were measured for both the OTCIXS I and the proposed OTCIXS 11 protocol. 
The effects of missed or lost messages were not key concerns of this effort. The loss of 
traffic is caused by many factors including the quality of transmit/receive equipment, 
atmospheric conditions, and satellite performance characteristics; these are difficult to 
mode and only a crude approximation can be simulated. The loss of messages is assumed 
to affect both protocols the same; thus, the main emphasis is on determining how the 
differences in the two protocols effect overall performance. Rather than concentrating on 
those functions of network performance related to transmission quality, this analysis 
concentrates on the network access and control characteristics. 
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Each protocol operates in cycles. These cycles provide the ability for subscribers 
to request and use the network for transmitting data to other subscribers. The different 
protocols manage these cycles differently. This analysis measures the functions affected 
by the different cycle management schemes and attempts to compare OTCIXSI 
performance to that of the proposed OTCIXS 11. 

Performance of both protocols is measured in a non-DAMA aivironment. Both 
protocols operate in non-DAMA environments, and this provides compatible results that 
can be used to compare one protocol to the other. The proposed OTCIXS n protocol is 
also measured in a DAMA environment; these results are useful in determining and 
degradation of OTCIXS n performance in a DAMA environment. 

1. Queue Wait Times. 

Queue wait time is the measure of time between receipt of a message in a 
subscriber and the transmission of the message over the network, i.e., the amount of time 
messages are queued in the subscriber before transmission. This time includes delays that 
result from access transmission requests, request collisions, cycle times, and, in the case of 
the proposed OTIXS H protocol, access scheduling. The shorter the queue wait time for 
a message the timelier the data in the message is. Thus, shorter queue wait times indicate 
better performance. This allows measuring the effects of the differrait cycle management 
techniques on netwoik access. 

2. Message Throughput Times. 

Message throughput time is the measure of time between receipt in the source 
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device to receipt of the message in the destinations device; message throughput is divided 
into subscriber to subscriber (link controller to link controller) and tactical data processor 
(TDP) or teletype (TTY) to TDP or TTY throughput times. These times are use&l in 
measuring the effects transmitting data more than one time. The OTCIXSI protocol 
transmits TDP data separately from TTY data; the OTCDCS11 proposed protocol does 
not. Message throughput time provides a method of measuring this difference in 
operation. 

3. Message Throughput Rate. 

Message throughput rates are the measure of number of messages over the 
network. For purposes of this analysis, message throughput rate is the number of 
messages transferred from one subscriber to another subscriber or subscribers. This 
measure is used to attempt to determine the upper bound of message throughput for the 
network. This is needed to determine if the network protocol is anticipated to satisfy the 
specification objective of200 messages per hour. 

4. Network Utilization. 

Network Utilization is the measure of network time used for data transmission. 
This measure is a percentage of the total available time and the amount of time used to 
transmit network control data, access requests, and subscriber data. Network utilization 
measures the amount of network time lost due to idle time, guard times, and network 
inefficiencies. 
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APPENDIX C - Section C2 


DESCRIPTION 


A.OTCIXSIMODEL. 

The OTCIXSI model is based on the currently operational protocol for the 
OTCEXS network. This protocol includes variable network access request time slots, 
transmission units which include either datalink or teletype messages, but not both at 
the same time, and transmission of the net control block (NCB) before transmission of 
each copy of the transmission unit (TU). The network is designed to operate in a non- 
DAMA UHF environment. Subscribers gain access to the network by demanding use of 
the network, and can preempt use of the network from lower priority message 
transmissions. 

Subscribers in the OTCIXS I network gain access to the network to transmit data 
by transmitting access requests during periods of time reserved for request demands. 
There is one high priority request time slot (PRTS) reserved exclusively for use by 
subscribers who have flash message traffic to transmit. There are up to 19 general access 
request time slots (GATS) for use by subscribers with flash or immediate message traffic. 
The PRTS and GATS intervals are discontinued once a subscriber demands use of the 
network. Thus, any one cycle has between one and twenty request time slots, but does 
not necessarily have all twenty every time. 

The NCB precedes the request slots in every cycle. After the request time slots 
interval is the time dedicated to the subscribers for transmission of data. A cycle consists 
of the NCB, the PRTS and GATS, and one copy of a data TU if there is one. An idle 
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cycle is a cycle during which not data is transmitted. A single access time slot (SATS) 
cycle is a cycle during which one copy of a data TU is transmitted. Each copy of a 
multiple copy TU is preceded by a NCB transmission. 

In summary, the OTCIXSI network protocol preceded subscriber transmission 
with the transmission of a NCB. Up to twenty request time slots were provide to 
subscribers to demand access to the network, but the request time slot interval is 
discontinued when the first demand transmission takes place; and each copy of a TU is 
preceded by the transmission of the NCB. Also, the model developed to analyze OTCIXS 
I performance does not include scheduled broadcast traffic. 

The simulation program was designed to implement these fimctions with 
assumptions on how the network operated. These assumptions include the effects of 
signal-to-noise on data transmissions, cryptographic equipment probability for sequence 
failure, and message throughput distributions. The simulation program provides a means 
of analyzing network performance based on the functional operation of the network and 
algorithms that model performance characteristics, assumed or known to occur in an UHF 
environment. 

B. OTCIXS n MODEL 

The proposed OTCIXS n network protocol incorporates several changes to the 
current protocol. These include providing all request time slots in every cycle; sending all 
copies of a data TU when network access is granted by the NCS; and once the network is 
granted to a subscriber to transmit data, no other subscriber can preempt the network 
fi-om the transmitting subscriber. The specific details of how the OTCIXS n network 
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operates can be found in the body of this thesis. The model provides the ability to perform 
different variations in network operations. 

The OTCIXS11 protocol allows for a variable number of flash and immediate 
message random access time slots (RATS); the NCB identifies how many of each type of 
access time slot is available during the next cycle. Subscriber demands, received as 
requests transmitted during the RATS, for access to the network to transmit data are 
scheduled by the NCS and queued on a first-in, first-out (FIFO) order by request priority. 
All allocated request time slots are provided during each cycle, and the request time slot 
interval is not truncated when the first demand is transmitted, as is the case in the 
OTCIXS I protocol. The OTCIX n protocol currently allows high priority requests to 
use any of the available request slots, and are not limited to using only the dedicated high 
priority request slot(s). The OTCIXS 11 protocol provides a mechanism to schedule 
subscribers without requiring them to demand access during the request time slot interval. 

The two methods currently under consideration, that have been modeled, are “piggy¬ 
backing”, i.e., a request for access in the TU, and providing a list of subscribers that are 
automatically polled, i.e., automatically scheduled for network access without the 
necessity of demanding access. 

The OTCIXS 11 protocol provides for transmission of all buffered messages in the 
subscriber station when access to the network is granted. The TU will contain either flash 
and immediate datalink and teletype messages. TUs are limited to 10103 bytes of message 
data plus the overhead data bytes needed for the TU. This is intended to reduce the 
number of access requests a subscriber should need to make to transmit buffered 
messages. 
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The simulation program has been modified to perform these functions based on the 
assumptions and message generation algorithms used in the OTCIXSI simulation 
program. As much as possible of the original simulation model has been maintained with 
the new functional definitions and performance characteristics layered onto them. This 
will provide some comparative analysis of the OTCIXS 11 performance with respect to the 
OTCIXS I analysis. 

1. OTCIXS Simulation Components. 

The OTCIXS simulation consists of three components. The first is the program; 
the set of instructions that perform the functional processing of the network. The second 
is the network model; the definitions of the subscriber and message generation 
characteristics. The third is the setup file; the parameters that allow quick and simple 
modifications of the data or processing of the simulation program. 

The simulation program consists of the algorithms for performing the functionally 
processing of the OTCIXS network. The algorithms for generating messages, simulating 
induced noise errors, and simulating cryptographic equipment synchronization failures 
have been left as originally designed. The OTCIXS I non-DAMA processing has also 
been left intact. The changes that have been made incorporated the new proposed 
protocol functionality/timing processing described in body of this thesis. The proposed 
new protocol processing is designed to perform the same cyclic functional operations 
whether non-DAMA or DAMA. The cycle interval times are adjusted to DAMA time slot 
values when the DAMA environment is being simulated. The message generation 
processing uses the three equations for message arrival patterns; Poisson, Negative 
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Binomial, and Periodic. However, the simulation program originally designed specified 
message traffic per hour as a parameter defined in the model definition. The program has 
been modified so that the model defines the percentage of total message per hour a 
specific subscriber generates, and the setup file defines the actual messages per hour value 
for the network as a whole. This change allows for more flexibility in simulating various 
different traffic rates without having to redefine the entire model. The message multiplier 
parameter in the setup file is still available, but its use affects subscriber percentage, not 
the actual traffic rate. 

a. Model Description. 

The simulation program consists of the algorithms needed to simulate the 
network operation. The data describing the subscribers, the types and characteristics of 
messages, and the frequency with which each subscriber generates the different types of 
messages is provided in a network description file (NDF). The NDF is produced by 
describing the subscriber and network characteristics in a network simulation description 
language (NSDL). The source is then converted into a binary interpretation used by the 
simulation program. Appendix A is a listing of the source NSDL used for this analysis. 
The following summarizes the characteristic used to analyze the proposed OTCIXS11 
protocol: 

1. The network model consists of 40 subscribers generating a non-uniform 
distribution of messages. This is accomplished by defining six of the subscribers as type 1 
(best), or type 2 (good) quality transmit stations, generating approximately 78 to 80 
percent of the message traffic. The remainder of the subscriber stations are type 2 or type 
3 (poorest) quality transmit stations equally generating 20 percent of the message traffic. 
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2. The model is designed to produce a mix of 80 percent immediate and 20 
percent flash messages, with 90 percent of the messages being datalink and 10 percent 
being teletype messages. 

3. Message generation distribution is poisson for all subscribers. 

4. The traffic load, messages per hour, is specified in the program setup 
file and is varied to simulate different traffic loads. 

5. The model is defined to generate 25 percent discrete-addressed and 75 
percent collective-addressed messages. There are six collective addressees defined with 
approximately equal probability for selection. 

6. Each subscriber has only one of the collective address values in its 
guard list. The six collective address values are equally distributed among the 40 
subscriber stations. 

b. Setup File Description. 

The program setup file allows the operator to fine tune the exercise for the 
current simulation. The setup file definition is functionally the same as the originally 
constructed for the OTCIXSI simulation. However, modifications have been made, these 
include; adding parameters to change the traffic load (messages per hour), the number of 
RATS, the number of RATS to be used for high priority requests, whether automatic 
piggy-backed requests processing is enabled, and selection of frequent users to be included 
in the automatic poll list. Appendbc B describes the setup file, including changes, used for 
this analysis. 

Some parameters have been deleted since they were not used: such things 
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as the header length of teletype messages and block byte count size parameter definition 
have been eliminated. The teletype message header size parameter has been deleted; the 
assumption is that the header and end of message bytes are included in the generated 
message size and do not need to be added in separately. The block byte count size 
parameter is calculated based on the maximum block byte count size parameter specified 
in the setup file. 

Several parameters in the setup file were set to the same values for all 
scenarios tested. The network is defined to transmit 8-bit characters at 2400 PBS. The 
options used to differentiate the various scenarios and exercises are; 

1. The number of messages generated per hour 

2. The number of request slots available per cycle 

3. Whether the new protocol (OTCIXS H) or the old protocol is being 

simulated 

4. Whether DAMA mode processing is enabled for an OTCIXS 11 

simulation 

5. Whether piggy-backed rescheduling is enabled 

6. Whether frequent user polling is enabled and the subscribers to be 

polled. 


2. Automatic Rescheduling. 

The OTCIXS uses a demand request protocol to gain access of the network to 
transmit data. When several subscribers are actively transmitting data on the network. 
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there is a likelihood that more than one subscriber will transmit a request at the same time. 
This contention for the limited number of request slots results in poor use of the network, 
depending on such factors as how many requests have already been scheduled and the 
precedence of the requests that were lost. Automatic rescheduling of subscribers has been 
considered as a method of reducing the number of requests that would have to be made, 
thus reducing the contention fro a request slots available. The two methods under 
consideration at this time are piggy-back and frequent user polling. 

a. Piggy-hacked Requests. 

A piggy-backed request would be implemented by putting data into the TU 
header requesting use of the network as soon as available, based on the priority of the data 
to be transmitted. In essence, the request transmission is piggy-backed onto the data 
transmission. Subscribers can piggy-back a request based on various criteria, receipt of 
more data after transmission has begun or prediction that more data will soon arrive. The 
simulation program has been updated to emulate the first option. The simulation program 
determines if additional messages have been received in the Link Controller or are about 
to be transmitted from the TDP to the Link Controller. If either of these conditions is 
true, a piggy-backed request is indicated and the subscriber is automatically rescheduled 
for network access. No predictive algorithms have been modeled. 

b. Frequent Users Polling List. 

A polling list rescheduling mechanism has been built-in to the simulation 
program. When a subscriber ftansmits data on the network, the subscriber’s identification 
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number is checked to see if it is in the frequent users list. If it is, the subscriber is 
automatically rescheduled for an immediate message transmission. Subscribers are put 
into the frequent users list by parameters entered in the setup file. If no subscribers are 
identified as frequent users, then frequesnt user polling is in effect disabled. The model 
has been modified so that a frequent user subscriber always transmits when selected, in 
order to keep the frequent user in the scheduling list. This has resulted in emulation a no¬ 
data informing NCB that the network is not needed, but transmission of data indicating 
nothing is being sent or detection of a quiescent channel. 
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APPENDIX C - Section C3 


PERFORMANCE RESULTS 


A. TEST CRITERIA. 

In section 2 the model definition and setup files are described; these files provide 
the simulation program user the capability to simulate or test a large number of different 
combinations of network operational characteristics. This section discusses the tests that 
were run and their results. To achieve the goals of this analysis only a limited set of data 
was required. Only the necessary combinations of network characteristics were set up and 
tested to obtain this data. 

The data for this analysis was obtained by executing the simulation program using 
the model and setup file data described in section H. However, the simulation program 
gives only a rough approximation of the real world operation. The simulated testing of 
the OTCIXS n was based on the real world OTCIXSI historical program data, and 
cannot for certain determine whether the specified requirements will be satisfied. The test 
results provide data for basing comparisons on how different parameters affect operations. 
This is also the base for comparing OTCIXS I and OTCIXS 11 performance. The 
deficiencies in the data for OTCIXS I testing are the same for OTCIXS 11 test data. The 
same routines and algorithms were used for both protocols with the only differences being 
in the network cycle control routines. The validity of the conclusions drawn in the 
analysis are based on the validity of the program and model. Therefore, it is assumed, 
without proof, that the program and model are close approximations and provide results 
that are reasonable indications of performance. 
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Given the above assumption, the OTCIXS 11 proposed protocol tests use a 
minimum and maximum cycle time scenario. For the purposes of testing, the minimum 
cycle time si the net cycle using one high priority and two low priority RATS. The 
maximum cycle time is the net cycle using two high priority an six low priority RATS. 
These scenarios are tested with an increasing traffic load; the tests are performed again 
using the two different rescheduling techniques. 

The minimum RATS scenario produces the shortest OTCIXS 11 network cycle 
times, but also produces the greatest contention. The maximum RATS scenario produces 
the longest cycle times, but also reduces overall contention. The test data showed the 
following contention/collision performance. The minimum RATS scenario went from 
1.7% of the total number of requests colliding at 100 messages per hour to 8.6% of the 
total number of requests colliding at 400 messages per hour. The maximum RATS 
scenario went from 2.6% at 100 messages per hour to 6.3% at 400 messages per hour. 
The minimum scenario had 7 collisions at 100 messages per hour and 83 collisions at 400 
messages per hour. The maximum scenario had 11 collisions at 100 messages per hour 
and 51 collisions at 400 messages per hour. The minimum scenario had more total cycles 
with an approximate average of490 cycles per hour. The minimum scenario provided 
fewer overall opportunities for subscribers to request access to the network (based on 980 
cycles per hour time 3 RATS per cycle for a minimum and 490 times 8 for the maximum) 
and also had a higher percentage and total number of collisions. The conclusion is the 
minimum scenario provides shorter cycles but reduces the opportunity to request access to 
the network. However, this reduced access does not necessarily mean poorer use of the 
network. At lower traffic loads many of the cycles are idle, i.e., there is no data to 
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transmit. The following test cases are designed to show if the decreased number of RATS 
degrade or improve network performance. The OTCIXS11DAMA mode is also included 
with the non-DAMA mode results for both the minimum and maximum scenarios. The 
time interval difference skews the network cycle times higher, but the operational trends 
should still be comparable. 

Table C3-1 contains the simulation results for the OTCIXS I network. This data is 
used in comparing the results from the OTCIXS H simulation. The following subsections 
analyze how these different extremes affect message wait times, subscriber to subscriber 
times, and network utilization. 

B. SCENARIO 1: MINIMUM CYCLE. 

Table C3-2 and C3-3 summarizes the test result for the minimum cycle scenario. 
Figures C3-1 and C3-2 are graphical interpretations of the result values for the subscriber 
queue wait and the subscriber to subscriber service times against those of OTCIXS I. The 
data compared to table C3-1 shows very similar performance. The data shows that 
OTCIXS I queue wait times for high priority messages are shorter than those for OTCIXS 
n, but OTCIXS n low priority queue wait times are shorter than OTCIXS I. The DAMA 
operation uses the network time nearly the same as the non-DAMA operation, however 
the times are approximately 30% higher. The effective message throughput rates per hour 
are also very close the same for OTCIXS I and OTCIXS 11 non-DAMA, and OTCXS11 
DAMA 
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Table C3-1. OTCIXS I Simulation Data Results (non-DAMAMode in seconds) 
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Table C3-2. OTCDCSII Minimal Cycle Time (non-DAMA Mode in seconds) 
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Table C3-3. OTCIXS 11 Minimal Cycle Time (DAMA Mode in seconds) 
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C. SCENARIO 2: MAXIMUM CYCLE. 

Tables C3-4 and C3-5 summarize the test results for the maximum cycle scenario. 
Figures C3-3 and C3-4 are graphical interpretations of the results values for the subscriber 
queue wait, and subscriber to subscriber service times. The data compared to table C3-1 
shows that high priority subscriber to subscriber times for both OTCIXS I and OTCIXS 11 
non-DAMA are similar, with OTCIXS 11 DAMA bang higher. Low priority OTCIXS 11 
non-DAMA times were lower than either OTCIXS I or OTCIXS n DAMA Subscriber 
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queue wait time results were similar to subscriber to 

Table C3-4. OTCIXS H Maximum Cycle Time (non-DAMA Mode in seconds) 
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Table C3-5. OTCIXS II Maximum Cycle Time (DAMAMode in seconds) 
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Subscriber service times except that OTCIXS I high priority times were lower. The 
DAMA operation uses the network time slightly more than the non-DAMA operation, 
however OTCIXS I utilization percentages were higher. The effective message 
throughput rate per hour for non-DAMA was slightly higher than OTCIXS I while 
OTCIXS n DAMA was significantly higher than OTCIXS I. 


D. SCENAKIOS: MINIMAL CYCLE WITH PIGGY-BACK SCHEDULING. 

Tables C3-6 and C3-7 summarize the test results for the minimal cycle scenario 
with piggy-back scheduling. Figures C3-5 and C3-6 are graphical interpretations of the 
result values for subscriber to subscriber service and the subscriber queue wmt times 
against those for the minimum cycle with no rescheduling. The subscriber to subscriber 
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service time data from tables C3-6 and C3-7 compared to tables C3-2 and C3-3 show that 
both non-rescheduled and piggy-backed OTCIXS11 subscriber to subscriber service and 
subscriber queue wait times for either high or low priority messages are quite similar. 

E. SCENARIO 4: MBSIMUM CYCLE WITH FREQUENT USER POLLING. 

Tables C3-8 and C3-9 summarize the test results for the minimum cycle scenario 
with frequent user polling. Figures C3-7 and C3-8 are graphical interpretations of the 
result values for subscriber to subscriber and subscriber queue wait times against those for 
the minimum cycle with no rescheduling. The subscriber to subscriber service time data 
from tables C3-8 and C3-9 compared to tables C3-2 and C3-3 show that both non-DAMA 
frequent user polled and non-rescheduled high priority messages result in similar 
performance during scenarios with less than 400 messages per hour generated. This is 
also true for DAMA high priority messages. With low priority messages, non-rescheduled 
non-DAMA performed slightly better than low priority frequent user non-DAMA, while 
the poorest performance came from both frequent user and non-rescheduled DAMA. The 
effective message throughput per hour for frequent user polling was slightly higher for 
DAMA, but for the most part less for non-DAMA. 
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Table C3-6. OTCIXS H Minimum Cycle Time/Piggy-Backed Rescheduling 
(non-DAMA Mode in seconds) 
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Table 03-1. OTCIXS E Minimum Cycle Time/Piggy-Backed Rescheduling 

(TDAMA Mode in seconds) 
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Table C3-8. OTCIXS E Minimum Cycle Time Frequent User Polling 
(non-DAMA Mode in seconds) 
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Table C3-9. OTCDCS n Minimum Cycle Time Frequent User Polling 
(DAMA Mode in seconds) 
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F. SCENARIO 5: MAXIMUM CYCLE WITH PIGY-BACK SCHEDULING. 

The tables C3-10 and C3-11 summarize the test results for the maximum <q?cle 
scenario with piggy-back rescheduling. Figures C3-9 and C3-10 are graphical 
interpretations of the result values for subscriber to subscriber queue wait times against 
those for the maximum cycle with no rescheduling. The subscriber to subscriber service 
time data from tables C3-10 and C3-11 compared to table C3-4 and C3-5 show non- 
DAMA high priority messages tended to be lower overall, with piggy-back scheduling 
times shorter during traffic loads of200 to 300 messages per hour, but increasing 
significantly for traffic loads of greater than 300 messages per hour. The same is true for 
' non-DAMA low priority messages. All DAMA subscriber to subscriber service times 
tended to be higher overall. Subscriber queue wait times followed the same trend as 
subscriber to subscriber service times. Network utilization for piggy-back scheduling and 
non-rescheduled non-DAMA operations were fairly similar until the 300 message level 
when non-rescheduled percentages were higher. Network utilization for piggy-back 
scheduling and non-scheduled DAMA operations were fdrly even. Effective message 
throughput per hour was similar between piggy-back scheduling and non-scheduling. 


170 













































Table C3-10. OTCIXS n Maximum Cycle Time/Piggy-Back Rescheduling 
(non-DAMA Mode in seconds) 
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Table C3-11. OTCIXS n Maximum Cycle Time/Piggy-Back Rescheduling 

(DAMA Mode in seconds) 
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G. SCENARIO 6: MAXIMUM CYCLE WITH FREQUENT USER POLLING. 

Tables C3-12 and C3-13 summarize the test results for the maximum cycle scenario 
with frequent user polling. Figures C3-11 and C3-12 are graphical interpretations of the 
result values for subscriber to subscriber service and subscriber queue wait times against 
those of the maximum cycle with no rescheduling. The subscriber to subscriber service 
time data from tables 3-12 and C3-13 compare to tables C3-4 and 3-5 show non-DAMA 
high priority message sendee times the shortest and fairly even. Non-rescheduled non- 
DAMA low priority service times were better than their frequent user polled counterparts. 
Similarly to scenario 5, all DAMA subscriber to subscriber service times tended to be 
higher overall. Subscriber queue wait times paralleled the same trend as subscriber to 
subscriber which tends to be much higher than its non-rescheduled counterpart. Non- 
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rescheduled network utilization percentages were slightly higher than frequent user 

polling, while effective message throughput per hour was fairly even. 

Table C3-12 OTCIXS n Maximum Cycle Time Frequent User Polling 
(non-DAMA Mode in seconds) 
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Table C3-13 OTCIXS n Maximum Cycle Time Frequent User Polling 
(DAMA Mode in seconds) 
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H. SUMMARY AND CONCLUSIONS. 

The OTCIXS I upper effective message throughput is about 300 messages per 
hour. The OTCIXS 11 non-DAMA upper effective message throughput was about 250 
messages per hour. While OTCIXS n DAMA appears to have an upper effective message 
throughput of about 325 messages per hour, there seems to be some timing conditions 
involved. Under certain conditions OTCIXS n DAMA can reach more than 300 
messages per hour, but at a cost. As the system generates more than 300 messages per 
hour, the subscriber queue wait time increases significantly. 

The OTCIXS n protocol provides better performance for low priority messages. 
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The servicing of high priority message is comparable for both protocols. The data also 
shows OTCIXS n DAMA operations perform as well as non-DAMA operations 
considering message throughput and utilization, but with higher wait and throughput 
times. If the assumption is true that DAMA will exhibit fewer contention events resulting 
in mutual destruction, then DAMA should use the avmlable request opportunities that are 
provided. Frequent user polling tends to show poorer performance indicated by longer 
queue wait times. 
















Figure C3-2. OTCIXSI vs. OTCEXS n Minimum Subscriber to Subscriber Service Time 
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Figure C3-3. OTCIXSI vs. OTCIXS n Maximum Subscriber Queue Wait Time 











Figure C3-4. OTCEXS I vs. OTCIXS n Maximum Subscriber to Subscriber Service Time 




177 







Figure C3-5. OTCIXS n Minimum^ non-Rescheduled vs. Piggy-Back Queue Wait Time 













Figure C3-6. OTCIXS n MMmum: non-Rescheduled vs. Piggy-Back Service Time 














Figure C3-7, OTCIXS n Minimum: non-Rescheduled vs. Frequ^t User Queue Wait Time 
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Figure C3-8. OTCEXS n Minimum : non-Rescheduled vs. Frequent User Service Time 
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Figure C3-9. OTCDCS n Maximum; ncm-Rescheduled vs. Piggy-Back Queue Wait Time 








Figure C3-10. OTCEXS n Maximum; non-Rescheduled vs. Piggy-Back Service Time 
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Figure C3-11. OTCIXS n Maximum; luai-Rescheduled vs. Frequent User Queue Wait Time 
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APPENDIX C - SECTION C4 


OTCIXS MODEL NETWORK DESCRimON 


The following is the source descriptions used to produce the OTCIXS network 
description file (NDF). This source was converted to the binary NDF using the OCTEDT 
program developed by Advanced Digital Systems (ADS). 


ISECT 

NETWORK = OTCIXS; 

DATE = “4 MAY 1999” 

SCENARIO =1; 

ENDS; 

MSECT 

DEFINE MESSAGE = TTYA; 

TYPE = TTY; 

SELECT PRECEDENCE = (<1:0.8>, <2:0.2>); 

SELECT COLLECTIVE = (<128:0.18>, <129:0.17>, <I30:0.17>, <131:0,16>, 

<132;0.16>, <133;0.16>); 

SELECT NADRPM = (<1:0.9> <2:0.08>, <3;0.02>); 

SELECT LENGTH = (< 100;0.10>,< 500:0.03>,< 550:0.05>, < 600:0.07>, 

< 650:0.09>, < 700:0.10>,< 800:9.11>,< 900:0.10>, 

< 1000:0.09>,< I200:0.06>,< 1400:0.05>,< I600:0.04>, 

< 1800:0.02>, < 2000:0.01>, < 2500:0.0I>, < 3000:0.02>, 

< 4000:0.02>, < 6000:0.01>, < 7000:0.01>, < 8000:0.0I>); 

ENDDEF; 

DEFINE MESSAGE = TDPA 
TYPE = DATA; 

COPY TTYAPRECEDENCE; 

COPY TTYACOLLECTTVE; 

COPY TTYANADRPM; 

SELECT LENGTH = (< 100:0.10>,< 500:0.08>,< 600:0.07>, < 650:0.09>, 

< 700:0.10>,< 800:0.11>,< 900:9.10>,< 1000:0.09>, 

< 1200:0.06>,< 1400:0.05>,< 1600:0.04>,< 1800:0.02>, 

< 2000:0.01>, < 2500:0.01>, < 3000:0.01>, < 4000:0.02>, 

< 6000:0.01>, < 7000:0.01>, < 8000:0.0I>, <10000:0.01>); 

ENDDEF; 

ENDS; 

NSECT 

DEFINE PLATFORM = AAOl; 
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TYPE = SHORE; 

SID =1; 

DEFINE DEVICE = TTY; 

CHANNEL = (75.0, 7.5,0.00001,0); 
ENDDEF; 

DEFINE DEVICE = TDP, 

CHANNEL = (4800.0, 8.0,0.0001,1); 
ENDDEF; 

DECLAIR SLCPARAM 

MAXMEM = 32367; 

PENALTY = 0.001; 

GUARD = (128); 

NOISE = BURST (20.0,0.03,8.0, 12.0); 
CLASS = TYPEl; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA02; 

TYPE = SHIP; 

. SID = 2; 

COPY AAOl.DEVICE.TTY; 

COPY A001.DEVICE.TDP; 

DECLARE SLCPARAM; 

MAXMEM= 32367; 

PENALTY = 0.002; 

GUARD = (129); 

NOISE = BURST (12.0,0.05, 8.0,12.0); 
CLASS = TYPE2; 

ENDP; 

ENDDEF; 


DEFINE PLATFORM = AA03; 
TYPE = SHIP; 

SID = 3; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM; 
GUARD = (130); 

ENDP; 

ENDDEF; 


DEFINE PLATFORM = AA04; 
TYPE = SHIP; 

SID = 4; 

COPY AA01.DEViaE.TTY; 
COPY A001.DEVICE.TDP, 
COPY A002.SLCPARAM; 
DECXARE SLCPARAM 
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GUARD = (131); 

NOISE = BURST (10.0,0.08, 8.0,12.0); 
CLASS = TYPE1; 

ENDF, 

ENDDEF; 


DEFINE PLATFORM = AA05; 

TYPE = SHIP; 

SID = 5; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA06; 
TYPE = SHIP; 

SID = 6; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA07; 
TYPE = SHIP; 

SID = 7; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD =(128); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 


DEFINE PLATEORM = AA08; 
TYPE = SHIP; 

SID = 8; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (129); 
PENALTY = 0.007; 
CLASS = TYPE3; 

ENDP; 
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ENDDEF; 


DEFINE PLATFORM = AA09; 

TYPE = SHIP; 

SID = 9; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (130); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AAIO; 

TYPE = SHIP; 

SID = 10; 

COPY AA01.DEVTCE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (131); 
PENALTY = 0.001; 
CLASS = TYPE3; 

, ENDP; 

ENDDEF; 

DEFINE PLATFORM = AAl 1; 
TYPE = SHIP; 

SID =11; 

COPY AAOLDEYICE.ITY; 
COPY A001.DEVICE.TDP, 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA12; 
TYPE = SHIP; 

SID = 12; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 
PENALTY = 0.002; 
CLASS = TYPE3; 


ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA13; 

TYPE = SHIP; 

SID= 13; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (128); 
PENALTY = 0.001; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA14; 

TYPE = SHIP; 

SID=14; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SL(3PARAM; 
DECLARE SLCPARAM 
GUARD = (129); 
reNALTY = 0.001; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA15; 

TYPE = SHIP; 

SID= 15; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP, 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (130); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA16; 
TYPE = SHIP; 

SID = 16; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP, 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD =(131); 
PENALTY = 0.001; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 



DEFINE PLATFORM = AA17; 
TYPE = SHIP; 

SID = 17; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVTCE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA18; 
TYPE = SHIP; 

SID =18; 

COPY AAO1 .DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 
PENALTY = 0.001; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA19; 
TYPE = SHIP; 

SID = 19; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.1DP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (128); 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA20; 
TYPE = SHIP; 

SID = 20; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (129); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA21; 
TYPE = SHIP, 

SID = 21; 

COPY AA01.DEVICE.TTY; 
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COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (130); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA22; 

TYPE = SHIP; 

SID = 22; 

COPY AA01.DEVICE.TTY; 
COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (131); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA23; 

TYPE = SHIP; 

SID = 23; 

COPY AAOLDEVICE.TTY; 
COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA24; 

TYPE = SHIP; 

SID = 24; 

COPY AAOLDEVICE.TTY; 
COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 
PENTALTY = 0;002; 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA25; 

TYPE = SfflP; 

SID = 25; 

COPY AAOLDEVICE.TTY; 
COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (128); 



PENTALTY = 0.002; 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA26; 

TYPE = SHIP; 

SID = 26; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (129); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA27; 

TYPE = SHOP; 

SID = 27; 

COPY AA01.DEVICE.TTY; 
COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (130); 
PENALTY = 0.001; 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA28; 

TYPE = SHIP; 

SID = 28; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (131); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA29; 

TYPE = SHIP; 

SID = 29; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDF, 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
CLASS = TYPES; 

ENDP; 

ENDDEF; 


DEFINE PLATFORM = AA30; 

TYPE = SHIP; 

SID = 30; 

COPY AAOl.DEVICE.TTY; 
COPY AOOIDEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA31; 

TYPE = SHIP; 

SID =31; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (128); 
CLASS = TYPE3; 

ENDP, 

ENDDEF; 

DEFINE PLATFORM = AA32; 

TYPE = SHIP; 

SID = 32; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD =(129); 
PENALTY = 0.002; 
CLASS = TYPE3; 

ENDP, 

ENDDEF; 

DEFINE PLATFORM = AA33; 

TYPE = SHIP, 

SID = 33; 

COPY AAOl.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD =(133); 
CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA34; 

TYPE = SHIP; 

SID=34; 

COPY AA01.DEVICE.rrY; 




COPY AOOl.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (131); 
PENALTY = 0.001; 
CLASS = TYPES; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA35; 

TYPE = SHIP; 

SID = 35; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
CLASS = TYPES; 

ENDP, 

ENDDEF; 

DEFINE PLATFORM = AA36; 

TYPE = SHIP; 

SID = 36; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (133); 
CLASS = TYPES; 

ENDP, 

ENDDEF; 

DEFINE PLATFORM = AA37; 

TYPE = SHIP, 

SID = 37; 

COPY AA01.DEVICE.TTY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
GUARD = (132); 
PENALTY = 0.008; 
CLASS = TYPES; 

ENDP; 

ENDDEF; 


DEFINE PLATFORM = AA38; 

TYPE = SHIP, 

SID = 38; 

COPY AA01.DEVICE.TrY; 
COPY A001.DEVICE.TDP; 
COPY A002.SLCPARAM; 
DECLARE SLCPARAM 
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GUARD = (131); 

CLASS = TYPE3; 

ENDP; 

ENDDEF; 

DEFINE PLATFORM = AA39; 

TYPE = SHIP; 

SID = 39; 

COPY AA01.DEVICE.TTY; 

COPY AOOLDEVICE.TDP; 

COPY A002.SLCPARAM; 

DECLARE SLCPARAM 
GUARD = (130); 

NOISE = BURST(6.0,0.8,5.0,6.3); 
CLASS = TYPE3; 

ENDP; 

ENDDEF; ' 

DEFINE PLATFORM = AA40; 

TYPE = SHIP; 

SID = 40; 

COPY AAOl.DEVICE.TTY; 

COPY A001.DEVICE.TDP; 

COPY A002.SLCPARAM; 

DECLARE SLCPARAM 
GUARD = (129); 

CLASS = TYPE3; 

ENDF, 

ENDDEF; 


ENDS; 

DECLARE SOURCE 
PLATFORM = AA01; 

DEVICE = TDP; 

MSG = 1DPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<I:0.09>,<2;0.08>,<3:0.02>); 
ARRIVALS = POISSON(0.21); 

ENDP; 


DECLARE SOURCE 
PLATFORM = AA01; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SEI^CT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>); 
ARRIVALS = POISSON(0.34); 
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ENDP; 


DECLARE SOURCE 
PLATFORM = AA04; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<I:0.9>,<2:0.08>,<3;;0.02>); 
SELECT NADRPM = (<I;0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.09); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA04; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECnVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.025); 

ENDP, 

DECLARE SOURCE 
PLATFORM = AA02; 

DEVICE = TDP, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<I:0.9> <2;0.08>,<3::0.02>); 
SELECT NADRPM = (<I:0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.10); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA02; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(O.OI); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA03; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
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SELECT NADRPM = (<1:0.09>,<2;0.08>,<3;0.02>); 
ARRIVALS = POISSON(0.14); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA03; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<I:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.009); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA05; 

DEVICE = TDP, 

MSG = TDPA; 

USE DISC3IETE = 0.25; 

SELCET DISCRETE =*; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;:0.02>); 
SELECT NADRPM = {<I:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.07); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA05; 

DEVICE = TTY; 

MSG = rrYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = ♦; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08> <3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>); 
ARRIVALS = POISSON(0.009); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA06; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<I:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2;0.08>,<3:0.02>); 
ARRIVALS = POISSON(0,08); 

ENDP; 

DECLARE SOURCE 
ILATFORM = AA06; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 
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SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1;0.09>,<2;0.08>,<3;0.02>); 
ARRIVALS = POISSON(0.009); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA13; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.20); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA13; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1;0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.009); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA14; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2;0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.25); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA18; 

DEVICE = TTY; 

MSG = TTYA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM - (<1:0.09>,<2:0.08> <3:0.02>): 
ARRIVALS = POISSON(0.025); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA19; 

DEVICE = TDP; 
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MSG = TDPA; 

USE DISCRETE = 0.25; 

QT7T PFT riT^^P'RFTF = ** 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.025); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA07; 

DEVICE = TDP; 

MSG = 1DPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08> <3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDR 

DECLARE SOURCE 
PLATFORM = AA08; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2;0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDR 

DECLARE SOURCE 
PLATFORM = AA09; 

DEVICE = TDR 
MSG = TDPA; 

USE DISCRETE = 0.25; 

SHLCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08> <3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON{0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA10; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SHJECT COLLECTIVE = (<1:0.9>,<2;0.08> <3;:0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
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PLATFORM = AA11; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA12; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;:0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA15; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;:0.02>); 
SELECT NADRPM = (<1;0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA16; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2;0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDF, 

DECLARE SOURCE 
PLATFORM = AA17; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;:0.02>); 
SELECT NADRPM = (<1;0.09> <2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 
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DECLARE SOURCE 
PLATFORM = AA20; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COUECITVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA2I; 

DEVICE = IDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA22; 

DEVICE = TOP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

Sn.CET DISCRETE =*; 

SEUECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA23; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SHLCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA24; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1;0.9>,<2;0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>); 
ARRIVALS = POISSON(0.003); 
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ENDP; 


DECLARE SOURCE 
PLATFORM = AA25; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELC^ DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA26; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECnVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA27; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = ♦; 

SELECT COLLECTIVE = (<1;0.9>,<2;0.08>,<3;:0.02>); 
SELECT NADRIM = (<1:0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA28; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3:;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM =AA29; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
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SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA30; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA31; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA32; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = ♦; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>;<3::0.02>); 
SELECT NADRPM = (<1;0.09>,<2;0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDF, 

DECLARE SOURCE 
PLATFORM = AA33; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3;:0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDF, 

DECLARE SOURCE 
PLATFORM = AA34; 

DEVICE = TDF, 

MSG = TDPA; 

USE DISCRETE = 0.25; 
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SELCET DISCRETE = *; 

SELECT COU^CnVE = (<1:0.9>,<2;0.08>,<3::0.02>); 
SEUECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA35; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<I:0.9>,<2:0.08>,<3;;0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>); 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA36; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISOREIE = *; 

SELECT COLLECTIVE = (<1:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2;0.08>,<3;0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP, 

DECLARE SOURCE 
PLATFORM = AA37; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLLECTIVE = (<1;0.9>,<2;0.08>,<3;:0.02>); 
SELECT NADRPM = (<1;0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA38; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COUECnVE = (<I:0.9>,<2:0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON{0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA39; 

DEVICE = TDR 
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MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SH^CT COLLECTIVE = (<1;0.9>,<2:0.08>,<3;:0.02>); 
SEUECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 

DECLARE SOURCE 
PLATFORM = AA40; 

DEVICE = TDP; 

MSG = TDPA; 

USE DISCRETE = 0.25; 

SELCET DISCRETE = *; 

SELECT COLI^CnVE = (<1:0.9>,<2;0.08>,<3::0.02>); 
SELECT NADRPM = (<1:0.09>,<2:0.08>,<3:0.02>): 
ARRIVALS = POISSON(0.003); 

ENDP; 
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APPENDIX D 


OTCIXSII MODEL SIMULATION SETUP FILE FORMAT 

A. INTRODUCTION. 

The OTCIXS 11 simulation setup file is used to specify run time parameters. The 
network description file (NDF) specifies the network subscriber and traffic characteristics; 
the setup file identifies the environment characteristic for the subscribers. These 
characteristic include such items as which NDF to use, non-DAMA or DAMA (including 
the OTCIXS n DAMA model), the net control station, data block sizes, transfer rates and 
other types of enwonment parameters. 

The setup file format allows the user to specify parameter data for several exerdses. 
This feature allows for several variations of environmental characteristics to be run against 
one or more NDF definitions. Thus analysis of various types and methods of OTIXS link 
operations can be performed. The following subsections describe the format and contents 
of the setup file. 

B. GENERAL FORMAT 

The setup file is a text file using standard ASCII. Each record in the file has a one 
character record code identifier as its first non-blank character. The record code is 
followed by one or more blanks and then auxiliary information related to the record code. 
The general format of the setup file record is as follows: 

CPARAMDATA 

Where: 
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c 


- Record Code 


PARAM - Parameter identifier (if any) 

DATA - Data (if any) 


C. RECORD CODES 

The following is a list of the record codes in the setup file. 


RECORD CODE 

A 

C 

D 

E 


F 


I 

M 

N 

P 


Q 

R 


DESCRIPTION 

Enables OTCDCS11 model. This code must be included in each 
exercise that runs an OTCIXSII model. 

Specifies the Crypto synchronization up link and down link factors 
Enables DAMA model and DAMA bit oror rates. This model runs 
the non-DAMA OTCIXS model using a DAMA transmit/recdve 
device simulation. This model is different fi’om the OTCIXS n 
model; the OTCIXS 11 model is a network protocol designed 
specifically to operate in a DAMA environment. 

Specifies the name of the even history file. This record is required 
Specifies subscriber to satellite DAMA signal strength (figure of 
merit (FOM)) characteristics based on three class types of 
subscribers such that type 1 subscribers have very good signal 
quality, type 2 subscribers have fair signal quality, and type 3 
subscribers have poor quality signals. The subscriber with the best 
FOM value will override other subscribers when a transmit 
contention condition occurs. 

Specifies the name of the NDF. This record is required. 

This record specifies a traffic multiplier that is applied to all traffic 
sources. This value is multiplied to the rate factor in the NDF that 
spedfies subscriber message traffic. 

Title of the current simulation. 

Specifies signal to noise values. Only one pair can be specified per 
record, and at least one record must be specified. However, these 
values ordy need to be defined once, and will be used by all 
succeeding exercises. If these values are not defined, those 
equations that use signal/noise values to compute transmission 
errors will produce erroneous results. 

Specifies link environment parameters such as net control station, 
subscriber link data rate, etc. 

Spedfies four values to be used as initial (seed) values for 
computing random numbers. These values must be spedfied at 
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least the first time the simulation is run. 

S Specified the scenario identifier and exercise identifier. 

T Specifies the termination criteria for this exercise. 

X Specifies the name of the summary file. This record is required. 

The slash (/) character specifies the end of the parameters for a 
given exercise. Any parameters that follow will be used for the 
next Kcercise. This process continues until the end of setup file 
condition occurs. An end of file condition will terminate the 
simulation; thus, the last exercise should end with the slash 
character followed by the end of file. 


D. SPECIFIC RECORD CODE FORMATS 

a. OTCDCS n Enable 
A 

Note: the A stands for SATLE^-A; this is a cany over fi-om the original program that 
referred to a new experimental protocol as S ATLINK-A. This experimental protocol was 
incorporated into the OTCIXS n protocol. 

b. Crypto Synchronization Factors 
C dnlf uplf didf uplf dnlf uplf 

Where: 

dnlf - Real number specifying the down link performance, 
uplf - Real number specifying the up link performance, 
c DAMA Mode 

D berlb berub berlb berup berlb berub 

Where: 

berlb - Bit error rate lower bound, 
berup - Bit error rate upper boimd. 
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d. Event History File 

E filespec 

Where: 

filespec - file specification (30 characters or less) in the form 
device: [directory]filename.extersnion;revision . The device and directory default to the 
current user area. The cycle defaults to the most recent. 

e. DAMA Figure Of Merit 

F fomlb fomub fomlb fomub fomlb fomub 

Where: 

fomlb - figure of merit lower bound. The value should be a real number between 0 
and 1 The three pairs of numbers are used for the three different type class of subscriber 
transmit signal quality. 

fomup - figure of merit upper bound. 

f. Network Description File 

I filespec 

Where: 

filespec- file specification (30 characters of less) in the form 
device: [directory]filename.execution;revision. The device and directory default.to the 
current user area. The cycle defaults to the most recent. This file name must be the output 
file fi'om the OTCEDT program. 

g. Traffic Multiplier 

M number 

Where: 
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number- Real number used to change the subscriber transmission rates. Default is 1. 
h. Simulation Title 


N title 


Where: 


Title - 1 to 60 ASCn characters 
i Signal/Noise Specification 
P snr per 


Where; 


snr - Signal noise ration; this value should be between the low signal noise and high 
signal noise values, inclusive, used in the 1®F model definition (NOISE = BURST 
(initiation time, average duration, low signal noise, high signal noise)). 

per - Signal error rate probability; the grater this value, the greater the probability 


of noise burst errors occuring. 


j. Link Environmental Parameters 


ADRSIZ 

integer 

ADVUSR 

integer 

BLKSIZ 

integer 

CHKSUM 

integer 

CRYPTO 

00 

GDTSIZ 

real 

HPRRS 

integer 

LBPS 

real 

LRATE 

real 

MAXADR 

integer 

MAXCPY 

integer 

MSGCHK 

integer 

MSGHDR 

integer 

MSGHP 

integer 

NCSID 

sid 

PTRBYT 

integer 

PTRCHK 

integer 

RCVMDO 

{T.F} 
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RRSGDT real 

RESCHD 

TOTRRS integer 

TTYMAX integer 

Where: 

ADRSIZ - Length in bytes per datalink message address. Range of values: 1 to 4. 
Default: 2. 

ADVUSR- Specifies frequent users polling list. The numbers must correspond to 
the subscriber identification numbers used in the NDF definitions. The subscribers in the 
polling hst are automatically acknowledged/polled for low priority data transmissions. 
Range of values: 1 to number of subscribers. Default: None 

BLKSIZ - Number of bytes per data block. Range of values: 64 to 1024. Default: 

256. 

CHKSUM - Number of bytes per each data block’s checksum. Range of values: 0 
to 4. Default: 2. 

CRYPTO - Crypto device type of KG-84. Range of value: 84. Default: 84 
GDTSIZ - Guard time in seconds. Range of values: 0.0 to 1.0. Default: 0.25. 
HPRRS - Specifies the number of high priority reservation request slots. Range of 
values: 1 to 20. Default: 1. 

LBPC - Number bits/charactw transferred. Range of values: 6.0 to 10.5. Default: 

8.0 

LRATE - Subscriber satellite transfer rate in bits/second. Range of values: 75.0 to 
19200.0. Default: 2400.0. 

MAXADDR - Maximum number of addresses per message. Ignored by simulator. 
Range of values: 0 to 8. Default: 5. 
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MAXCPY - Number of times a subscriber uplinks transmission units (TU) will be 
transmitted in a SATS or BUSY cycle. A value of zero activates dynamic computation of 
the number of transmits based on the subscriber class type defined in the NDF (type 1 is 
best quality transmission and type 3 is poorest quality). Range of values: 0 to 5. Default: 2. 

MSGCHK - Length in bytes of datalink message checksum. Range of values: 0 to 
4. Default: 2. 

MSGHDR - Length of datalink message header. Ignored by simulator. Range of 
values: 0 to 16. Default: 0 (included in data length). 

MSGPH - Number of messages per hour to be generated in the network by all 
subscribers. Range of values: 10 to 1000. Default: 140. 

NCSID - Net control station identifier. Must be one of the subscribers identifiers 
assigned in the NDF. Range of values: 1 to total number of subscribers. Assumes 
subscribers are assigned sequential numbers starting with 1. Default: 1. 

PTRBYT - Number of bytes per datalink TU message pointer. Range of values: 0 
to 4. Default: 2. 

PTRCHK - Number of bytes per datalink TU pointer block checksum. Range of 
values: 0 to 4. Default: 2. 

RCVMOD - Message processing takes place after every copy (TRUE) or after last 
copy (FALSE). Range of values: TRUE, FALSE. Default: FALSE. 

RESCHD - Enables automatic “piggy-backing” of link access during transmission 
unit processing. The default state is no piggy-backed rescheduling; this option turns it on. 
Range of values: None. Default: False condition. 

RRSGDT - Reservation request slot guard time. Valid for non-DAMA link 
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operations. Range of values; 0.0 to 1.3. Default; 0.5. 

TOTRRS - Total number of reservation request slots. Range of values; 3 to 20. 
Default; 8. 

TTYMAX - Maximum length of TTY messages, in bytes. Range of values; 1024 
to 8192. Default; 8000. 

Note; These parameters persist from one wcercise to the next and need only be entered 
when they change from the default or the last entered value. 
k. Random Number Seed 
R integer integer integer integer 

Where; 

integer - Number used as initial value for random number generation. 

L Scenario Exercise Specification 
S scenario exercise 

Where; 

scenario - Integer identifying the scenario 

exercise - Integer identifying the exercise in the current scenario 

m. Termination Criteria 

T ttymsg datamsg maxtime 

Where: 

ttymsg — Integer indicating maximum number of TTY messages to be sent. 
Default: 10. 

datamsg - Integer indicating maximiun number of datalink messages to be sent. 
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Default: 50. 


maxtime - Real numbw indicating maximum simulation time. Not clock time or 
computer time, but simulated clock time. Time interval is entered in seconds. Default: 
1200.0 

n. Summary File 
X filespec 

Where: 

filespec - file specification (30 characters or less) in the form, 
device: [directory]filename.extension;revision. The device and directory default to the 
current user area. The cycle defaults to the most recent. 
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APPENDIX E 


SETUP FILE STANDARD VALUES 

A. NON-DAMA PARAMETERS 

OTCEXS n 

I MODELl.NDF 

R 127 73 149 29 

C 0.9787 0.9787 0.9587 0.9587 0.9344 0.9344 
F 0.7 1.0 0.5 0.8 0.3 0.6 

P 8.00 0.0000145 

P 8.45 0.000015 

P 8.90 0.0000155 

P 9.35 0.000016 

P 9.80 0.0000165 

P 10.25 0.000017 

P 10.70 0.0000175 

P 11.15 0.000018 

P 11.60 0.0000185 

P 12.00 0.000019 

Q LBPC 8.0 

Q LRATE 2400.0 

Q NCSID 4 

T 100 1000 18000 

B. DAMA PARAMETERS 

N OTCIXS n 

A 

D 0.000015 0.00002 0.000005 0.00001 0.0000015 0.000004 
I MODELl.NDF 

R 127 73 149 29 

C 0.9787 0.9787 0.9587 0.9587 0.9344 0.9344 
F 0.7 1.0 0.5 0.8 0.3 0.6 


p 

8.00 

0.0000145 

p 

8.45 

0.000015 

p 

8.90 

0.0000155 

p 

9.35 

0.000016 

p 

9.80 

0.0000165 

p 

10.25 

0.000017 

p 

10.70 

0.0000175 

p 

11.15 

0.000018 

p 

11.60 

0.0000185 
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P 12.00 0.000019 

Q LBPC 8.0 

Q LRATE 2400.0 
Q NCSID 4 

T 100 1000 18000 
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